Patent Application 18670355 - SYSTEMS AND METHODS FOR MULTI-ENTITY

Title: SYSTEMS AND METHODS FOR MULTI-ENTITY BLOCKCHAIN-BASED EVENT BREAK PREVENTION
Application Information

Invention Title: SYSTEMS AND METHODS FOR MULTI-ENTITY BLOCKCHAIN-BASED EVENT BREAK PREVENTION
Application Number: 18670355
Submission Date: 2025-05-13T00:00:00.000Z
Effective Filing Date: 2024-05-21T00:00:00.000Z
Filing Date: 2024-05-21T00:00:00.000Z
Examiner Employee Number: 94444
Art Unit: 3699
Tech Center: 3600
Rejection Summary

102 Rejections: 0
103 Rejections: 6
Cited Patents

No patents were cited in this rejection.
Office Action Text



    DETAILED ACTION
Notice of Pre-AIA  or AIA  Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .

Status of Claims
This is the final office action in response to the applicant’s arguments/remarks field on March 3, 2025.
Claims 1 and 12 have been amended.
Claims 1-20 are pending and have been examined.

Priority
The applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.

Information Disclosure Statement
The information disclosure statements (IDS), submitted on 12/10/2024, 01/27/2025, and 03/03/2025, are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.


Responses to Arguments/Remarks
Claim Objections:
The amended claims have overcome the claim objections, and the claim objections have been withdrawn.

Double Patenting:
The amended claims do not overcome the double patenting rejection, and the double patenting rejection remains.

35 USC § 112 rejection:
The amended claims have overcome most of the 112 rejections. The applicant is advised to refer to the 112 rejection section for details.

35 USC § 103 rejection:
The applicant’s amendments have overcome the 35 U.S.C. § 103 rejection. However, there are new grounds of rejection necessitated by the applicant’s amendments as detailed in the 35 U.S.C. § 103 rejection section. Hence, the applicant’s arguments with respect to the claim rejection have been considered but are moot in view of the new grounds of rejection.

Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA  as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). 
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.

Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,020,241 (’241 patent). Although the claims at issue are not identical, they are not patentably distinct from each other.
The mapping of claims 1-20 of this application with claims 1-20 of the ’241 patent is as follows:
               This Application
                Patent No. 12,020,241
Claim 1:
A system comprising: a plurality of nodes each corresponding to a computing device having a processor and memory to store data, the plurality of nodes comprising a plurality of sets of nodes, each set of nodes maintaining a different blockchain and corresponding to a different type of destination, wherein one or more computing devices of the plurality of nodes are configured to: 

receive, from a first computing device, a first event request corresponding to a pending event between the first computing device and a second computing device, the first event request comprising a first set of event attributes corresponding to the pending event; 

receive, from a second computing device, a second event request corresponding to the pending event between the first computing device and the second computing device, the second event request comprising a second set of event attributes corresponding to the pending event; 

divide the first set of event attributes into a plurality of first subsets of event attributes and the second set of event attributes into a plurality of second subsets of event attributes based on a table indicating types of attributes to send to different types of destinations; and 

transmit the plurality of first subsets of event attributes and the plurality of second subsets of event attributes to the plurality of sets of nodes based on types of destinations of the plurality of sets of nodes such that each of the plurality of sets of nodes receives a different first subset of the plurality of first subsets of event attributes and a different second subset of the plurality of second subsets of event attributes, each first subset of the plurality of first subsets of event attributes having at least one type of event attribute different from a type of event attribute included in another first subset of the plurality of first subsets of event attributes























































wherein a set of nodes of the plurality of sets of nodes appends a block instance corresponding to the pending event to a blockchain maintained by the set of nodes based on a first subset of event attributes and a second subset of event attributes received by the set of nodes.
Claim 1:
A system comprising: a plurality of nodes each corresponding to a computing device having a processor and memory to store data, the plurality of nodes comprising a plurality of sets of nodes, each set of nodes maintaining a different blockchain and corresponding to a different type of destination, wherein one or more computing devices of the plurality of nodes are configured to: 

receive, from a first computing device, a first event request corresponding to a pending event between the first computing device and a second computing device, the first event request comprising a first set of event attributes corresponding to the pending event; 











divide the first set of event attributes into a plurality of first subsets of event attributes based on a table indicating types of attributes to send to different types of destinations; 



transmit the plurality of first subsets of event attributes to the plurality of sets of nodes based on types of destinations of the plurality of sets of nodes such that each of the plurality of sets of nodes receives a different first subset of the plurality of first subsets of event attributes, each first subset of the plurality of first subsets of event attributes having at least one event attribute different from another first subset of the plurality of first subsets of event attributes; 




receive, from the second computing device, a second event request corresponding to the pending event between the first computing device and the second computing device, the second event request comprising a second set of event attributes corresponding to the pending event; 

divide the second set of event attributes into a plurality of second subsets of event attributes based on the table indicating types of attributes to send to the different types of destinations; and 

transmit the plurality of second subsets of event attributes to the plurality of sets of nodes based on the types of destinations of the plurality of sets of nodes such that each of the plurality of sets of nodes receives a different second subset of the plurality of second subsets of event attributes, each second subset of the plurality of second subsets of event attributes having at least one event attribute different from another second subset of the plurality of second subsets of event attributes, wherein each set of nodes of the plurality of sets of nodes: 

maintains a blockchain; appends a first block instance comprising a first subset of event attributes corresponding to the pending event of the plurality of first subsets of event attributes that the set of nodes receives to the blockchain; 
retrieves the first subset of event attributes corresponding to the pending event of the plurality of first subsets of event attributes that the set of nodes receives from the first block instance of the blockchain in response to receiving a second subset of event attributes corresponding to the pending event of the plurality of second subsets of event attribute; automatically executes an electronic protocol to compare the first subset of event attributes corresponding to the pending event of the plurality of first subsets of event attributes that the set of nodes receives with the second subset of event attributes corresponding to the pending event of the plurality of second subsets of event attributes that the set of nodes receives; and 
responsive to determining the first subset of event attributes corresponding to the pending event that the set of nodes receives matches the second subset of event attributes corresponding to the pending event that the set of nodes receives, appends a second block instance corresponding to the pending event to the blockchain maintained by the set of nodes.
Claim 2:
wherein the first computing device communicates the pending event with the second computing device via a private channel that is not accessible to other computing devices.
Claim 2:
wherein the first computing device communicates the pending event with the second computing device via a private channel that is not accessible to other computing devices.
Claim 3:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, the first set of nodes maintaining a first blockchain, and the second computing device corresponds to a second set of nodes, and wherein the first set of nodes: appends, to the first blockchain, a third block instance comprising the first subset of the first set of event attributes corresponding to the pending event; receives, from the second set of nodes, the second subset of the second set of event attributes corresponding to the pending event; retrieves the first subset of event attributes from the third block instance; compares the first subset of event attributes with the second subset of event attributes; and responsive to determining the first subset of event attributes matches the second subset of event attributes, appends a fourth block instance corresponding to the pending event to the first blockchain, the fourth block instance indicating successful completion of the pending event.
Claim 3:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, the first set of nodes maintaining a first blockchain, and the second computing device corresponds to a second set of nodes, and wherein the first set of nodes: appends, to the first blockchain, a third block instance comprising the first subset of the first set of event attributes corresponding to the pending event; receives, from the second set of nodes, the second subset of the second set of event attributes corresponding to the pending event; retrieves the first subset of event attributes from the third block instance; compares the first subset of event attributes with the second subset of event attributes; and responsive to determining the first subset of event attributes matches the second subset of event attributes, appends a fourth block instance corresponding to the pending event to the first blockchain, the fourth block instance indicating successful completion of the pending event.
Claim 4:
wherein the first set of nodes: appends a fifth block instance to the first blockchain between the third block instance and the fourth block instance, the fifth block instance comprising the second subset of event attributes; and retrieves the second subset of event attributes from the fifth block instance, wherein the first set of nodes compares the retrieved second subset of event attributes with the first subset of event attributes.
Claim 4:
wherein the first set of nodes: appends a fifth block instance to the first blockchain between the third block instance and the fourth block instance, the fifth block instance comprising the second subset of event attributes; and retrieves the second subset of event attributes from the fifth block instance, wherein the first set of nodes compares the retrieved second subset of event attributes with the first subset of event attributes.
Claim 5:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, and wherein the first set of nodes: executes a first electronic protocol to transmit a third subset of event attributes of the first set of event attributes to a second set of nodes of the plurality of sets of nodes; executes a second electronic protocol to transmit a fourth subset of event attributes of the second set of event attributes to a third set of nodes of the plurality of sets of nodes; and executes a third electronic protocol to transmit a fifth subset of event attributes of the second set of event attributes to a fourth set of nodes of the plurality of sets of nodes.
Claim 5:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, and wherein the first set of nodes: executes a first electronic protocol to transmit a third subset of event attributes of the first set of event attributes to a second set of nodes of the plurality of sets of nodes; executes a second electronic protocol to transmit a fourth subset of event attributes of the second set of event attributes to a third set of nodes of the plurality of sets of nodes; and executes a third electronic protocol to transmit a fifth subset of event attributes of the second set of event attributes to a fourth set of nodes of the plurality of sets of nodes.
Claim 6:
wherein the first set of nodes executes the first electronic protocol, the second electronic protocol, and the third electronic protocol by respectively executing a first smart contract, a second smart contract, and a third smart contract.
Claim 6:
wherein the first set of nodes executes the first electronic protocol, the second electronic protocol, and the third electronic protocol by respectively executing a first smart contract, a second smart contract, and a third smart contract.
Claim 7:
wherein the third set of nodes: receives the fourth subset of event attributes from the first set of nodes; appends, to a blockchain maintained by the third set of nodes, a third block instance comprising the fourth subset of event attributes; receives a sixth subset of event attributes of the second set of event attributes from the second set of nodes; compares the fourth subset of event attributes with the sixth subset of event attributes; and appends a fourth block instance to the blockchain maintained by the third set of nodes in response to determining a match between the fourth subset of event attributes and the sixth subset of event attributes.
Claim 7:
wherein the third set of nodes: receives the fourth subset of event attributes from the first set of nodes; appends, to a blockchain maintained by the third set of nodes, a third block instance comprising the fourth subset of event attributes; receives a sixth subset of event attributes of the second set of event attributes from the second set of nodes; compares the fourth subset of event attributes with the sixth subset of event attributes; and appends a fourth block instance to the blockchain maintained by the third set of nodes in response to determining a match between the fourth subset of event attributes and the sixth subset of event attributes.
Claim 8:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, wherein the first set of nodes: transmits a third subset of event attributes of the first set of event attributes for the pending event and a fourth subset of event attributes of the second set of event attributes for the pending event to a second set of nodes; and wherein the second set of nodes: appends a third block instance comprising the third subset of event attributes for the pending event to a blockchain maintained by the second set of nodes; and appends a fourth block instance comprising the fourth subset of event attributes for the pending event to the blockchain maintained by the second set of nodes.
Claim 8:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, wherein the first set of nodes: transmits a third subset of event attributes of the first set of event attributes for the pending event and a fourth subset of event attributes of the second set of event attributes for the pending event to a second set of nodes; and wherein the second set of nodes: appends a third block instance comprising the third subset of event attributes for the pending event to a blockchain maintained by the second set of nodes; and appends a fourth block instance comprising the fourth subset of event attributes for the pending event to the blockchain maintained by the second set of nodes.
Claim 9:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, the first set of nodes maintaining a first blockchain, and the second computing device corresponds to a second set of nodes, and wherein the first set of nodes: appends, to the first blockchain, a third block instance comprising the first subset of the first set of event attributes corresponding to the pending event; receives, from the second set of nodes, the second subset of the second set of event attributes corresponding to the pending event; retrieves the first subset of event attributes from the third block instance; compares the first subset of event attributes with the second subset of event attributes; and responsive to determining the first subset of event attributes does not match the second subset of event attributes, generate an alert indicating the first subset of event attributes does not match the second subset of event attributes.
Claim 9:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, the first set of nodes maintaining a first blockchain, and the second computing device corresponds to a second set of nodes, and wherein the first set of nodes: appends, to the first blockchain, a third block instance comprising the first subset of the first set of event attributes corresponding to the pending event; receives, from the second set of nodes, the second subset of the second set of event attributes corresponding to the pending event; retrieves the first subset of event attributes from the third block instance; compares the first subset of event attributes with the second subset of event attributes; and responsive to determining the first subset of event attributes does not match the second subset of event attributes, generate an alert indicating the first subset of event attributes does not match the second subset of event attributes.
Claim 10:
wherein the one or more computing devices are configured to: determine an attribute type for each event attribute of the first set of event attributes and the second set of event attributes; and determine whether the event attributes of the first set of event attributes match corresponding event attributes of the second set of event attributes based on the determined attribute types.
Claim 10:
wherein the one or more computing devices are configured to: determine an attribute type for each event attribute of the first set of event attributes and the second set of event attributes; and determine whether the event attributes of the first set of event attributes match corresponding event attributes of the second set of event attributes based on the determined attribute types.
Claim 11:
wherein the pending event is a pending exchange of assets.
Claim 11:
wherein the pending event is a pending exchange of assets.
Claim 12:
A method comprising: receiving, by one or more computing devices of a plurality of nodes and from a first computing device, a first event request corresponding to a pending event between the first computing device and a second computing device, the first event request comprising a first set of event attributes corresponding to the pending event; 



receiving, by the one or more computing devices from a second computing device, a second event request corresponding to the pending event between the first computing device and the second computing device, the second event request comprising a second set of event attributes corresponding to the pending event; 

dividing, by the one or more computing devices, the first set of event attributes into a plurality of first subsets of event attributes and the second set of event attributes into a plurality of second subsets of event attributes based on a table indicating types of attributes to send to different types of destinations; and 

transmitting, by the one or more computing devices, the plurality of first subsets of event attributes and the plurality of second subsets of event attributes to the plurality of sets of nodes based on types of destinations of the plurality of sets of nodes such that each of the plurality of sets of nodes receives a different first subset of the plurality of first subsets of event attributes and a different second subset of the plurality of second subsets of event attributes, each first subset of the plurality of first subsets of event attributes having at least one type of event attribute different from a type of event attribute included in another first subset of the plurality of first subsets of event attributes, 




























































wherein a set of nodes of the plurality of sets of nodes appends a block instance corresponding to the pending event to a blockchain maintained by the set of nodes based on a first subset of event attributes and a second subset of event attributes received by the set of nodes.
Claim 12:
A method comprising: receiving, by one or more computing devices of a plurality of nodes and from a first computing device, a first event request corresponding to a pending event between the first computing device and a second computing device, the first event request comprising a first set of event attributes corresponding to the pending event, the plurality of nodes comprising a plurality of sets of nodes corresponding to a different type of destination; 










dividing, by the one or more computing devices, the first set of event attributes into a plurality of first subsets of event attributes based on a table indicating types of attributes to send to different types of destinations; 



transmitting, by the one or more computing devices, the plurality of first subsets of event attributes to the plurality of sets of nodes based on types of destinations of the plurality of sets of nodes such that each of the plurality of sets of nodes receives a different first subset of the plurality of first subsets of event attributes, each first subset of the plurality of first subsets of event attributes having at least one event attribute different from another first subset of the plurality of first subsets of event attributes; 





receiving, by the one or more computing devices from the second computing device, a second event request corresponding to the pending event between the first computing device and the second computing device, the second event request comprising a second set of event attributes corresponding to the pending event; 

dividing, by the one or more computing devices, the second set of event attributes into a plurality of second subsets of event attributes based on the table indicating types of attributes to send to the different types of destinations; and 

transmitting, by the one or more computing devices, each of the plurality of second subsets of event attributes to a different set of the plurality of sets of nodes based on the types of destinations of the plurality of sets of nodes such that each of the plurality of sets of nodes receives a different second subset of the plurality of second subsets of event attributes, each second subset of the plurality of second subsets of event attributes having at least one event attribute different from another second subset of the plurality of second subsets of event attributes, wherein each set of nodes of the plurality of sets of nodes: maintains a blockchain; appends a first block instance comprising a first subset of event attributes corresponding to the pending event of the plurality of first subsets of event attributes that the set of nodes receives to the blockchain; retrieves the first subset of event attributes corresponding to the pending event of the plurality of first subsets of event attributes that the set of nodes receives from the first block instance of the blockchain in response to receiving a second subset of event attributes corresponding to the pending event of the plurality of second subsets of event attributes; automatically executes an electronic protocol to compare the first subset of event attributes corresponding to the pending event of the plurality of first subsets of event attributes that the set of nodes receives with the second subset of event attributes corresponding to the pending event of the plurality of second subsets of event attributes that the set of nodes receives; and

 responsive to determining the first subset of event attributes corresponding to the pending event that the set of nodes receives matches the second subset of event attributes corresponding to the pending event that the set of nodes receives, appends a second block instance corresponding to the pending event to the blockchain maintained by the set of nodes.
Claim 13:
wherein the first computing device communicates the pending event with the second computing device via a private channel that is not accessible to other computing devices.
Claim 13:
wherein the first computing device communicates the pending event with the second computing device via a private channel that is not accessible to other computing devices.
Claim 14:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, the first set of nodes maintaining a first blockchain, and the second computing device corresponds to a second set of nodes, and the method comprises: appending, by the first set of nodes to the first blockchain, a third block instance comprising the first subset of the first set of event attributes corresponding to the pending event; receiving, by the first set of nodes from the second set of nodes, the second subset of the second set of event attributes corresponding to the pending event; retrieving, by the first set of nodes, the first subset of event attributes from the third block instance; comparing, by the first set of nodes, the first subset of event attributes with the second subset of event attributes; and responsive to determining the first subset of event attributes matches the second subset of event attributes, appending, by the first set of nodes, a fourth block instance corresponding to the pending event to the first blockchain, the fourth block instance indicating successful completion of the pending event.
Claim 14:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, the first set of nodes maintaining a first blockchain, and the second computing device corresponds to a second set of nodes, and the method comprising: appending, by the first set of nodes to the first blockchain, a third block instance comprising the first subset of event attributes of the first set of event attributes corresponding to the pending event; receiving, by the first set of nodes from the second set of nodes, the second subset of event attributes of the second set of event attributes corresponding to the pending event; retrieving, by the first set of nodes the first subset of event attributes from the third block instance; comparing, by the first set of nodes, the first subset of event attributes with the second subset of event attributes; and responsive to determining the first subset of event attributes matches the second subset of event attributes, appending, by the first set of nodes, a fourth block instance corresponding to the pending event to the first blockchain, the fourth block instance indicating successful completion of the pending event.
Claim 15:
appending, by the first set of nodes, a fifth block instance to the first blockchain between the third block instance and the fourth block instance, the fifth block instance comprising the second subset of event attributes; retrieving, by the first set of nodes, the second subset of event attributes from the fifth block instance; and comparing, by the first set of nodes, the retrieved second subset of event attributes with the first subset of event attributes.
Claim 15:
appending, by the first set of nodes, a fifth block instance to the first blockchain between the third block instance and the fourth block instance, the fifth block instance comprising the second subset of event attributes; and retrieving, by the first set of nodes, the second subset of event attributes from the fourth block instance; and comparing, by the first set of nodes, the retrieved second subset of event attributes with the first subset of event attributes.


Claim 16:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, and the method comprises: executing, by the first set of nodes, a first electronic protocol to transmit a third subset of event attributes of the first set of event attributes to a second set of nodes of the plurality of sets of nodes; executing, by the first set of nodes, a second electronic protocol to transmit a fourth subset of event attributes of the second set of event attributes to a third set of nodes of the plurality of sets of nodes; and executing, by the first set of nodes, a third electronic protocol to transmit a fifth subset of event attributes of the second set of event attributes to a fourth set of nodes of the plurality of sets of nodes.


Claim 16:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, and the method comprising: executing, by the first set of nodes, a first electronic protocol to transmit a third subset of event attributes of the first set of event attributes to a second set of nodes of the plurality of sets of nodes; executing, by the first set of nodes, a second electronic protocol to transmit a fourth subset of event attributes of the second set of event attributes to a third set of nodes of the plurality of sets of nodes; and executing, by the first set of nodes, a third electronic protocol to transmit a fifth subset of event attributes of the second set of event attributes to a fourth set of nodes of the plurality of sets of nodes.
Claim 17:
wherein the first set of nodes executes the first electronic protocol, the second electronic protocol, and the third electronic protocol by respectively executing a first smart contract, a second smart contract, and a third smart contract.
Claim 17:
wherein executing the first electronic protocol, the second electronic protocol, and the third electronic protocol comprises executing, by the first set of nodes and respectively, a first smart contract, a second smart contract, and a third smart contract.
Claim 18:
receiving, by the third set of nodes, the fourth subset of event attributes from the first set of nodes; appending, by the third set of nodes to a blockchain maintained by the third set of nodes, a third block instance comprising the fourth subset of event attributes; receiving, by the third set of nodes, a sixth subset of event attributes of the second set of event attributes from the second set of nodes; comparing, by the third set of nodes, the fourth subset of event attributes with the sixth subset of event attributes; and appending, by the third set of nodes, a fourth block instance to the blockchain maintained by the third set of nodes in response to determining a match between the fourth subset of event attributes and the sixth subset of event attributes.
Claim 18:
wherein the third set of nodes: receiving, by the third set of nodes, the fourth subset of event attributes from the first set of nodes; appending, by the third set of nodes to a blockchain maintained by the third set of nodes, a third block instance comprising the fourth subset of event attributes; receiving, by the third set of nodes, a sixth subset of event attributes from the second set of nodes; comparing, by the third set of nodes, the fourth subset of event attributes with the sixth subset of event attributes; and appending, by the third set of nodes, a fourth block instance to the blockchain maintained by the third set of nodes in response to determining a match between the fourth subset of event attributes and the sixth subset of event attributes.
Claim 19:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, and the method comprises: transmitting, by the first set of nodes, a third subset of event attributes of the first set of event attributes for the pending event and a fourth subset of event attributes of the second set of event attributes for the pending event to a second set of nodes; appending, by the second set of nodes, a third block instance comprising the third subset of event attributes for the pending event to a blockchain maintained by the second set of nodes; and appending, by the second set of nodes, a fourth block instance comprising the fourth subset of event attributes for the pending event to the blockchain maintained by the second set of nodes.
Claim 19:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, and the method comprising: transmitting, by the first set of nodes, a third subset of event attributes of the first set of event attributes for the pending event and a fourth subset of event attributes of the second set of event attributes for the pending event to a second set of nodes; appending, by the second set of nodes to a blockchain maintained by the second set of nodes, a third block instance comprising the third subset of event attributes for the pending event; and appending, by the second set of nodes, a fourth block instance comprising the fourth subset of event attributes for the pending event to the blockchain maintained by the second set of nodes.
Claim 20:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, the first set of nodes maintaining a first blockchain, and the second computing device corresponds to a second set of nodes, and the method comprises: appending, by the first set of nodes to the first blockchain, a third block instance comprising the first subset of the first set of event attributes corresponding to the pending event; receiving, by the first set of nodes from the second set of nodes, the second subset of the second set of event attributes corresponding to the pending event; retrieving, by the first set of nodes, the first subset of event attributes from the third block instance; comparing, by the first set of nodes, the first subset of event attributes with the second subset of event attributes; and responsive to determining the first subset of event attributes does not match the second subset of event attributes, generating, by the first set of nodes, an alert indicating the first subset of event attributes does not match the second subset of event attributes.
Claim 20:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, the first set of nodes maintaining a first blockchain, and the second computing device corresponds to a second set of nodes, and the method comprising: appending, by the first set of nodes to the first blockchain, a third block instance comprising the first subset of the first set of event attributes corresponding to the pending event; receiving, by the first set of nodes from the second set of nodes, the second subset of the second set of event attributes corresponding to the pending event; retrieving, by the first set of nodes, the first subset of event attributes from the third block instance; comparing, by the first set of nodes, the first subset of event attributes with the second subset of event attributes; and responsive to determining the first subset of event attributes does not match the second subset of event attributes, generating, by the first set of nodes, an alert indicating the first subset of event attributes does not match the second subset of event attributes.



Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b)  CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.


The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.


Claims 12-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA  35 U.S.C. 112, the applicant) regards as the invention.
Claim 12 recites “transmitting, by the one or more computing devices, the plurality of first subsets of event attributes and the plurality of second subsets of event attributes to the plurality of sets of nodes based on the types of destinations of the plurality of sets of nodes such that each of the plurality of sets of nodes receives a different first subset of the plurality of first subsets of event attributes and a different second subset of the plurality of second subsets of event attributes.” There is insufficient antecedent basis for “the plurality of sets of nodes” in the claim. Claim 12 recites a plurality of nodes but does not disclose a plurality of sets of nodes.
Claims 13-20 are rejected because they depend on the rejected claim 12.

Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA  35 U.S.C. 102 and 103 (or as subject to pre-AIA  35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA  to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.  
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.

The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.

Claims 1-2, 8, 10-13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lu et al. (US 20210150515 A1) in view of Yin et al. (CN 111080449 A), and further in view of Vo et al. (US 20190340267 A1) and Zheng et al. (CN 109523380 A).
Claims 1 and 12:
Lu discloses the following:
a plurality of nodes each corresponding to a computing device having a processor and memory to store data, the plurality of nodes comprising a plurality of sets of nodes, each set of nodes maintaining a different blockchain and corresponding to a different type of destination, wherein one or more computing devices of the plurality of nodes are configured to. (See paragraphs [0074]-[0075], “[i]n a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, which can be referred to as consensus nodes, one or more consensus nodes being operated by a respective entity [e.g., a financial institution, insurance company]”; Fig. 1; paragraph [0077], “[i]n the depicted example, the computing systems 106, 108 can each include any appropriate computing device that enables participation as a node in the consortium blockchain network 102”; Fig. 12; paragraph [0164]; paragraphs [0169]-[0170], “[a]fter the blockchain nodes verify the proofs that prove the legitimacy of the SBLC, the blockchain nodes can perform consensus and store the encrypted SBLC in one or more blocks to be appended to the first blockchain…. In some embodiments, verification data can be pre-stored in simple payment verification (SPV) nodes of the destination blockchain network”; and paragraphs [0336]-[00337].) 
receive, from a first computing device, a first event request corresponding to a pending event between the first computing device and a second computing device, the first event request comprising a first set of event attributes corresponding to the pending event. (See Fig. 12; paragraph [0164]; and paragraphs [0167]-[0170], “[a]s discussed in the description of FIG. 7, the applicant 702 and the beneficiary can agree on the terms of the SBLC, such as the guaranteed amount of loan in the SBLC…. After approval of the SBLC, the issuing bank 704 can finalize the SBLC source code, encrypt the SBLC source code, generate proofs, and include the encrypted SBLC and the proofs in a cross-chain request to the blockchain network 2 707…. For example, a blockchain node (e.g., a cloud node) connected to the issuing bank's 704 internal system can submit the cross-chain request for consensus…. At 1218, the relay 705 can relay the cross-chain request to the blockchain network 2 707.”)
receive, from a second computing device, a second event request corresponding to the pending event between the first computing device and the second computing device, the second event request comprising a second set of event attributes corresponding to the pending event. (See Fig. 12; paragraphs [0171]-[0174], “[t]he beneficiary bank 708 can then confirm the acceptance of the SBLC at 1222 and request the blockchain network 2 707 to record the updated SBLC status on a second blockchain associated with the blockchain network 2 707 through consensus. In some embodiments, the beneficiary bank 708 can also send a cross-chain request to deliver the confirmation to the issuing bank 708. At 1224, the blockchain network 2 707 can update the SBLC status on the second blockchain as ‘issued’ through consensus and deliver the confirmation to the relay 705…. At 1230, the issuing bank 704 can void the SBLC stored on the first blockchain in response to receiving the verification result and that the acceptance of the SBLC has been confirmed by the beneficiary bank 708.”)
transmit […] (the first subsets) of the first set of event attributes and […] (the second subsets) of the second set of event attributes to the plurality of sets of nodes. (See Fig. 12; paragraph [0164]; and paragraphs [0167]-[0174], “[f]or example, a blockchain node (e.g., a cloud node) connected to the issuing bank's 704 internal system can submit the cross-chain request for consensus…. At 1218, the relay 705 can relay the cross-chain request to the blockchain network 2 707…. In some embodiments, the beneficiary bank 708 can also send a cross-chain request to deliver the confirmation to the issuing bank 708. At 1224, the blockchain network 2 707 can update the SBLC status on the second blockchain as ‘issued’ through consensus and deliver the confirmation to the relay 705. At 1226, the relay 705 can verify that the SBLC is issued on the second blockchain, provide proof of the verification, and relay the confirmation of acceptance to the blockchain network 1 703…. At 1230, the issuing bank 704 can void the SBLC stored on the first blockchain in response to receiving the verification result and that the acceptance of the SBLC has been confirmed by the beneficiary bank 708.”)
wherein each set of nodes of the plurality of sets of nodes appends a block instance corresponding to the pending event to a blockchain maintained by a set of nodes based on a first subset of event attributes and a second subset of event attributes received by the set of nodes. (See Fig. 12; paragraph [0164]; and paragraphs [0167]-[0174], “[f]or example, a blockchain node (e.g., a cloud node) connected to the issuing bank's 704 internal system can submit the cross-chain request for consensus. After the blockchain nodes verify the proofs that prove the legitimacy of the SBLC, the blockchain nodes can perform consensus and store the encrypted SBLC in one or more blocks to be appended to the first blockchain…. At 1218, the relay 705 can relay the cross-chain request to the blockchain network 2 707…. At 1220, the blockchain network 2 707 records the cross-chain request through consensus and delivers the encrypted SBLC to the beneficiary bank 708. … In some embodiments, the beneficiary bank 708 can also send a cross-chain request to deliver the confirmation to the issuing bank 708. At 1224, the blockchain network 2 707 can update the SBLC status on the second blockchain as ‘issued’ through consensus and deliver the confirmation to the relay 705…. At 1230, the issuing bank 704 can void the SBLC stored on the first blockchain in response to receiving the verification result and that the acceptance of the SBLC has been confirmed by the beneficiary bank 708.”)


Lu does not explicitly disclose the following:
divide the first set of event attributes into a plurality of first subsets of event attributes and the second set of event attributes into a plurality of second subsets of event attributes based on a table indicating types of attributes to send to different types of destinations; and 
transmit the plurality of first subsets of event attributes and the plurality of second subsets of event attributes to the plurality of sets of nodes based on types of destinations of the plurality of sets of nodes such that each of the plurality of sets of nodes receives a different first subset of the plurality of first subsets of event attributes and a different second subset of the plurality of second subsets of event attributes, each first subset of the plurality of first subsets of event attributes having at least one type of event attribute different from a type of event attribute included in another first subset of the plurality of first subsets of event attributes.
However, Yin, an analogous art of processing cross-chain transactions, discloses divide the first set of event attributes into a plurality of first subsets of event attributes and the second set of event attributes into a plurality of second subsets of event attributes based on […] (transaction information) indicating types of attributes to send to different types of destinations and transmit the plurality of first subsets of event attributes and the plurality of second subsets of event attributes to the plurality of sets of nodes based on the types of destinations of the plurality of sets of nodes such that each of the plurality of sets of nodes receives a different first subset of the plurality of first subsets of event attributes and a different second subset of the plurality of second subsets of event attributes. (See paragraph 2 of Detailed Description, page 7, “Fig. 1 exemplarily shows a system architecture to which the method for providing a cross-chain transaction of a blockchain according to an embodiment of the present invention is applicable, where the system architecture may include N blockchain networks, a management node, and a client. Wherein N is greater than 1”; paragraph 3, page 8, “step 301, the management node receives a transaction to be executed sent by the client, and generates N preparation instructions corresponding to the N blockchain networks according to the transaction to be executed”; and paragraph 7, page 8, “[f]or example, the transaction to be executed is ‘transfer asset 100 of the first account of the blockchain network 1 to the second account of the blockchain network 2’, in practical implementation, that is, asset of the first account in the blockchain network 1 is subtracted by 100, and asset of the second account in the blockchain network 2 is added by 100, that is, the management node generates two preparation instructions to be respectively sent to the two blockchain networks, that is, generates a first preparation instruction ‘asset of the first account in the blockchain network 1 is subtracted by 100’ to be sent to the blockchain network 1, and generates a second preparation instruction ‘asset of the second account in the blockchain network 2 is added by 100’ to be sent to the blockchain network 2.” One of ordinary skill in the art knows that a blockchain network comprises a plurality of nodes that receive the transaction information transmitted to the blockchain network. The set of event attributes of “transfer asset 100 of the first account of the blockchain network 1 to the second account of the blockchain network 2” are divided into two subsets of “asset of the first account in the blockchain network 1 is subtracted by 100” and “asset of the second account in the blockchain network 2 is added by 100.” Each of the subsets is transmitted to the plurality of sets of nodes based on the different types of destinations, such as the blockchain network 1 and the blockchain network 2.)
Lu discloses that each set of nodes of the plurality of sets of nodes validates the first subsets of event attributes and the second subsets of event attributes. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Yin in the Lu system. Moreover, in order to improve the practicality of the Lu system, one of ordinary skill in the art would have been motivated to divide the transaction attributes based on the types of destinations and to transmit different first and second subsets of transaction attributes to different sets of nodes associated with different blockchain networks, so that each of the blockchain networks only needs to store the related transaction attributes and that the cross-chain transaction can be processed and/or executed by different blockchain networks based on the corresponding subsets of the transaction attributes.
The combination of Lu and Yin discloses the claimed invention but does not explicitly disclose the following:
a table indicating types of attributes to be sent to different types of destinations; 
each first subset of the plurality of first subsets of event attributes having at least one type of event attribute different from a type of event attribute included in another first subset of the plurality of first subsets of event attributes.
Vo, an analogous art of processing cross-chain transactions, discloses the following: dividing the attributes based on a table (i.e., the stored partitioning rule/information) indicating types of attributes to send to different types of destinations. (See Fig. 1; paragraph [0028], “[o]nce a partitioning policy is stored in the blockchain of the master chain 110, individual blockchain nodes in the master chain 110 may route transactions to other different blockchain networks (e.g., mixed chain 120, partitioned chains 132-136, etc.) based on the partition rules stored in the master chain. The partitioning rules/information stored by the master chain 110 may include data ranges allocated to each of the different partitioned chains 132, 134, and 136, which identifies data stored at each partitioned chain”; Fig. 4; and paragraph [0050], “[f]or example, the transaction router 414 may read the user information contained in the incoming transaction and the partition rule maintained in its blockchain 412 (i.e., the master chain or partition smart contract). As a non-limiting example, the transaction router 414 may identify that the data record associated with user ‘U1’ resides in partition A 432 whereas the data record associated with user ‘U2’ resides in partition B 434…. Then this transaction may be forwarded to the mixed chain 420 with the detail of ‘U1’, ‘U2’ and their blockchain node URLs…. Furthermore, the cross-chain handler 424 may create a transaction in its own blockchain 422 and also send ‘SetDiff’ transaction to U1's blockchain (partition A 432) with the delta of U1's balance and send a separate ‘SetDiff’ transaction to U2's blockchain (partition B 434) with the delta of U2's balance.” The rule, which stores the relationship between types of data and the corresponding blockchain, acts as a table indicating types of attributes to be sent to different types of destinations; for instance, the attributes associated with U1 are for the partition chain A, and the attributes associated with U2 are for partition chain B.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Vo in the Lu system as modified. Moreover, in order to improve the practicality of the Lu system as modified, one of ordinary skill in the art would have been motivated to divide the transaction attributes based on a table/rule, so that the transaction attributes can be effectively divided and transmitted to corresponding sets of nodes. 
The combination of Lu, Yin, and Vo discloses the claimed invention but does not explicitly disclose each first subset of the plurality of first subsets of event attributes having at least one type of event attribute different from a type of event attribute included in another first subset of the plurality of first subsets of event attributes.
Zheng, an analogous art of processing cross-chain transactions, discloses each first subset of the plurality of first subsets of event attributes having at least one type of event attribute different from a type of event attribute included in another first subset of the plurality of first subsets of event attributes. (Zheng discloses that different atomic transactions with different types of attributes are constructed for different blockchains based on a transaction request. The atomic transactions are broadcast to the corresponding blockchain. See paragraphs 3-4, page 5/12, “[t]he formats and contents of the atomic transaction information corresponding to different blockchain May be different. For example, the atomic transaction information corresponding to the blockchain 2 May include 100Y assets required by the account A2, provide 0 assets, and the account B2 requires 0 assets to provide 100 Y assets, and the atomic transaction information corresponding to the blockchain 1 May include the account A1 requirement 0 assets, 10 Z assets, and 10 Z assets required by the account B1 to provide 0 assets…. The atomic transaction information may be sent to a corresponding blockchain by broadcasting. By performing an uplink operation on the atomic transaction information, node verification may be performed, and if all nodes pass the verification, the uplink operation is successful.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Zheng in the Lu system as modified. Moreover, in order to improve the efficiency of processing a cross-chain transaction in the Lu system as modified, one of ordinary skill in the art would have been motivated to transmit different types of attributes to different blockchains, so that the cross-chain transaction can be processed via each blockchain based on the attributes required by the corresponding blockchain.

Claims 2 and 13:
Lu in view of Yin, Vo, and Zheng discloses the limitations shown above.
Lu further discloses wherein the first computing device communicates the pending transaction with the second computing device via a private channel that is not accessible to other computing devices. (See paragraphs [0094]-[0095], “[f]or example, in response to the verification, the KMS [as challenger] can issue asymmetric encryption keys [e.g., a public-key and private-key pair] to the node executing the TEE [e.g., through a key exchange process, such as elliptical curve Diffie-Hellman (ECDH)] to enable the node to securely communicate with other nodes, and/or clients.”)
	
Claims 8 and 19:
Lu in view of Yin, Vo, and Zheng discloses the limitations shown above.
Lu further discloses the following:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, wherein the first set of nodes. (See Fig. 12; paragraphs [0168]-[0169], “[a]fter approval of the SBLC, the issuing bank 704 can finalize the SBLC source code, encrypt the SBLC source code, generate proofs, and include the encrypted SBLC and the proofs in a cross-chain request to the blockchain network 2 707…. After the blockchain nodes verify the proofs that prove the legitimacy of the SBLC, the blockchain nodes can perform consensus and store the encrypted SBLC in one or more blocks to be appended to the first blockchain.”)
transmits a third subset of event attributes for the pending event and a fourth subset of event attributes for the pending event to a second set of nodes. (See Fig. 12; paragraph [0168], “[a]fter approval of the SBLC, the issuing bank 704 can finalize the SBLC source code, encrypt the SBLC source code, generate proofs, and include the encrypted SBLC and the proofs in a cross-chain request to the blockchain network 2 707”; and paragraphs [0171]-[0172], “[t]he beneficiary bank 708 can then confirm the acceptance of the SBLC at 1222 and request the blockchain network 2 707 to record the updated SBLC status on a second blockchain associated with the blockchain network 2 707 through consensus.”)
wherein the second set of nodes: appends, to a blockchain maintained by the second set of nodes, a third block instance comprising the third subset of event attributes for the ending event to a blockchain maintained by the second set of nodes. (See Fig. 12; paragraph [0171], “[a]t 1220, the blockchain network 2 707 records the cross-chain request through consensus and delivers the encrypted SBLC to the beneficiary bank 708.”)
appends a fourth blockchain instance comprising the fourth subset of event attributes for the pending event to the blockchain maintained by the second set of nodes. (See Fig. 12; paragraphs [0171]-[0172], “[t]he beneficiary bank 708 can then confirm the acceptance of the SBLC at 1222 and request the blockchain network 2 707 to record the updated SBLC status on a second blockchain associated with the blockchain network 2 707 through consensus…. At 1224, the blockchain network 2 707 can update the SBLC status on the second blockchain as ‘issued’ through consensus and deliver the confirmation to the relay 705.”)

Claim 10:
Lu in view of Yin, Vo, and Zheng discloses the limitations shown above.
Lu further discloses determine attribute types for each of the attributes of the first set of transaction attributes and the second set of transaction attributes; and determine whether the attributes of the first set of transaction attributes match corresponding attributes of the second set of transaction attributes based on the determined attribute types. (See Fig. 12; paragraphs [0171]-[0174]. These citations indicate that the transaction type of SBLC is validated.)

Claim 11:
Lu in view of Yin, Vo, and Zheng discloses the limitations shown above.
Lu further discloses wherein the pending event is a pending exchange assets. (See paragraph [0026], “[i]n some embodiments, the guarantee specifies that the guarantor shall pay the beneficiary a predetermined amount when the one or more predetermined conditions of executing the guarantee are met.”)

Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Lu et al. (US 20210150515 A1) in view of Yin et al. (CN 111080449 A), and further in view of Vo et al. (US 20190340267 A1), Zheng et al. (CN 109523380 A), and Antonopoulos (“Mastering Bitcoin,” December 2014).
Claims 3 and 14:
Lu in view of Yin, Vo, and Zheng discloses the limitations shown above.
Lu discloses the following:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, the first set of nodes maintaining a first blockchain, and the second computing device corresponds to a second set of nodes, and wherein the first set of nodes. (See Fig. 12; paragraph [0164]; and paragraphs [0168]-[0172].)
appends, to the first blockchain, a third block instance comprising a first subset of the first set of event attributes corresponding to the pending event. (See Fig. 12; paragraphs [0168]-[0169], “[a]fter approval of the SBLC, the issuing bank 704 can finalize the SBLC source code, encrypt the SBLC source code, generate proofs, and include the encrypted SBLC and the proofs in a cross-chain request to the blockchain network 2 707…. After the blockchain nodes verify the proofs that prove the legitimacy of the SBLC, the blockchain nodes can perform consensus and store the encrypted SBLC in one or more blocks to be appended to the first blockchain.”)
receives, from the second set of nodes, a second subset of the second set of event attributes corresponding to the pending event. (See Fig. 12; paragraphs [0171]-[0173], “[t]he beneficiary bank 708 can then confirm the acceptance of the SBLC at 1222 and request the blockchain network 2 707 to record the updated SBLC status on a second blockchain associated with the blockchain network 2 707 through consensus. In some embodiments, the beneficiary bank 708 can also send a cross-chain request to deliver the confirmation to the issuing bank 708…. At 1228, the blockchain nodes of the blockchain network 1 703 can verify the proof that the SBLC is issued on the second blockchain and deliver the verification result and the confirmation of acceptance to the issuing bank 704.”)
responsive to determining (that the attributes are valid), appends a fourth block instance corresponding to the pending event to the first blockchain, the fourth block instance indicating successful completion of the pending event. (See Fig. 12; paragraphs [0173]-[0174], “[a]t 1228, the blockchain nodes of the blockchain network 1 703 can verify the proof that the SBLC is issued on the second blockchain and deliver the verification result and the confirmation of acceptance to the issuing bank 704…. At 1230, the issuing bank 704 can void the SBLC stored on the first blockchain in response to receiving the verification result and that the acceptance of the SBLC has been confirmed by the beneficiary bank 708…. At 1232, the blockchain network 1 703 can update the SBLC status on the first blockchain as ‘void.’”)
None of Lu, Yin, Vo, and Zheng explicitly discloses the following:
retrieves the first subset of event attributes from the third block instance; 
comparing a first subset of event attributes with a second subset of event attributes; and 
responsive to determining the first subset of event attributes matches the second subset of event attributes, appends a block instance corresponding to the pending event to a blockchain, the block instance indicating successful completion of the pending event.
However, Antonopoulos, an analogous art of processing a blockchain transaction, discloses the following:
retrieves the first subset of event attributes from the third block instance; comparing a first subset of event attributes with a second subset of event attributes. (See page 132, “[f]or example, a 2-of-3 multi-signature is one where 3 public keys are listed as potential signers and at least 2 of those must be used to create signatures for a valid transaction to spend the funds…. A locking script setting a 2-of-3 multi-signature condition looks like this: 2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG The locking script above can be satisfied with an unlocking script containing pairs of signatures and public keys: OP_0 <Signature B> <Signature C> or any combination of two signatures from the private keys corresponding to the three listed public keys”; page 136, “[a] customer making a payment to Mohammed’s company need only include this much shorter locking script in their payment. When Mohammed wants to spend this UTXO, they must present the original redeem script (the one whose hash locked the UTXO) and the signatures necessary to unlock it, like this: <Sig1> <Sig2> <2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> The two scripts are combined in two stages. First, the redeem script is checked against the locking script to make sure the hash matches: <2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> OP_HASH160 <redeem scriptHash> OP_EQUAL If the redeem script hash matches, then the unlocking script is executed on its own, to unlock the redeem script: <Sig1> <Sig2> 2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG”; and pages 182-183, “[h]owever, before forwarding transactions to its neighbors, every bitcoin node that receives a transaction will first verify the transaction…. For each input, the referenced output must exist and cannot already be spent…. The unlocking scripts for each input must validate against the corresponding output locking scripts.”)
responsive to determining the first subset of event attributes matches the second subset of event attributes, appends a block instance corresponding to the pending event to a blockchain, the block instance indicating successful completion of the pending event. (See page 132; page 136; pages 182-183; page 184, “[a]fter validating transactions, a bitcoin node will add them to the memory pool, or transaction pool, where transactions await until they can be included (mined) into a block”; and pages 201-202, “[a]s the newly solved block moves across the network, each node performs a series of tests to validate it before propagating it to its peers. This ensures that only valid blocks are propagated on the network.” These citations indicate that a transaction is in a new block after it is validated by matching the attributes in the locking script and those in the unlocking script.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Antonopoulos in the Lu system as modified. Moreover, in order to improve the accuracy and security of the Lu system as modified, one of ordinary skill in the art would have been motivated to validate the pending transaction by comparing the received event attributes corresponding to the pending transaction and to include the validated transaction in the blockchain, so that the pending transaction can be verified by each node before it is broadcast to other nodes in the blockchain. This ensures that only valid transactions are propagated across the network, while invalid transactions are discarded at the first node that encounters them.

Claims 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Lu et al. (US 20210150515 A1) in view of Yin et al. (CN 111080449 A), and further in view of Vo et al. (US 20190340267 A1), Zheng et al. (CN 109523380 A), Antonopoulos (“Mastering Bitcoin,” December 2014), and Govindarajan et al. (US 20200074458 A1).
Claims 4 and 15:
Lu in view of Yin, Vo, Zheng, and Antonopoulos discloses the limitations shown above.
Lu discloses the first blockchain and the second subset of event attributes. (See Fig. 12; paragraphs [0171]-[0173].)
Antonopoulos discloses comparing a retrieved subset of event attributes with another subset of event attributes. (See page 132; page 136; and pages 182-183.)
None of Lu, Yin, Vo, Zheng, and Antonopoulos explicitly discloses appending a fifth block instance to the first blockchain between the third block instance and the fourth block instance, the fifth block instance comprising the second subset of event attributes; and retrieving the second subset of event attributes from the third block instance.
However, Govindarajan, an analogous art of processing a blockchain transaction, discloses appending a block instance (i.e., a transaction to transmit UTXOs to UTXOr) to a blockchain between a first block instance (i.e., a transaction for receiving the UTXOs) and a second block instance (i.e., the termination transaction), the third block instance comprising a set of event attributes and retrieving a second set of event attributes from the third blockchain instance. (See paragraphs [0047]-[0063]. One of ordinary skill in the art knows that the previous transactions may be retrieved in order to validate the inputs in the current transaction that are valid outputs from previous transactions).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Govindarajan in the Lu system as modified. Moreover, in order to improve the accuracy and security of the Lu system as modified, one of ordinary skill in the art would have been motivated to store the event attributes in the blockchain and validate the event based on the stored event attributes, so that the pending transaction can be verified and committed via the blockchain.

Claims 5-6 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable
over Lu et al. (US 20210150515 A1) in view of Yin et al. (CN 111080449 A), and further
in view of Vo et al. (US 20190340267 A1), Zheng et al. (CN 109523380 A), and Padmanabhan et al. (US 20200349564 A1).
Claims 5 and 16:
Lu in view of Yin, Vo, and Zheng discloses the limitations shown above.
Lu discloses wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, and wherein the first set of nodes; the first set of event attributes and the second set of event attributes; transmitting a subset of the first set of event attributes to a set of nodes; and transmitting a subset of the second set of event attributes to a set of nodes. (See Fig. 12; paragraph [0164]; and paragraphs [0168]-[0172].) Lu further discloses executing an electronic protocol to transmit a subset of event attributes to a set of nodes of the plurality of sets of nodes. (See paragraph [0132], “[f]or example, the issuing bank 704 can send the cyphertext of the encrypted SBLC to the blockchain network 706 by calling a smart contract on the blockchain associated with the blockchain network 706. In the description below, it is assumed that interactions with the blockchain network 706 are performed by calling relevant smart contracts on the blockchain”; Fig. 12; and paragraphs [0168]-[0172].)
None of Lu, Yin, Vo, and Zheng explicitly discloses executing a first electronic protocol to transmit a third subset of event attributes to a second set of nodes of the plurality of sets of nodes; executing a second electronic protocol to transmit a fourth subset of event attributes to a third set of nodes of the plurality of sets of nodes; and executing a third electronic protocol to transmit a fifth subset of event attributes to a fourth set of nodes of the plurality of sets of nodes.
However, Padmanabhan, an analogous art of processing cross-chain transactions, discloses executes a first electronic protocol to transmit a third subset of event attributes to a second set of nodes of the plurality of sets of nodes; executes a second electronic protocol to transmit a fourth subset of event attributes to a third set of nodes of the plurality of sets of nodes; and executes a third electronic protocol to transmit a fifth subset of event attributes to a fourth set of nodes of the plurality of sets of nodes. (See Fig. 1; paragraphs [0020]-[0021], “[i]n the example of FIG. 1 the interoperability network 103 is in communication with blockchain network A 101 and blockchain network B 102. However, the interoperability network 103 can service any number and variety of blockchain networks. The example of the interoperability network 103 servicing two blockchain networks is provided by way of example and not limitation. One skilled in the art would understand that the principles, structures, and operations of the interoperability network 103 can service any number and combination of blockchain networks…. Examples of existing blockchain protocols are utilized as part of cryptocurrencies (e.g., Bitcoin, and Ethereum), for data storage, smart contracts, and similar applications”; and paragraphs [0029]-[0031], “[t]he mapper 107 identifies the mappings to be applied by determining each of the other blockchain networks that are needed to resolve the transaction…. Matches with multiple blockchain networks are possible. With each map the transaction received from blockchain network A 101 can be mapped to a transaction in a matching blockchain network using mappings specific to the relationship between the blockchain network that emitted the transaction and the blockchain network with matching data. The interoperability network 103 can then emit the transformed transaction to the respective blockchain network.” These citations indicate that a transaction from one blockchain can be transformed and transmitted to different sets of nodes that maintain different blockchains.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Padmanabhan in the Lu system as modified. Moreover, in order to improve the practicality of the Lu system as modified, one of ordinary skill in the art would have been motivated to transmit the different sets of event attributes to different sets of nodes associated with different blockchain networks, so that mechanisms are provided to correlate information and transactions in one blockchain network with the information and transactions of other blockchain networks.
Claims 5 and 16 recite duplicated parts, such as a second electronic protocol, a third electronic protocol, a fourth subset of event attributes, a fifth subset of event attributes, a third set of nodes, and a fourth set of nodes. The mere duplication of parts has no patentable significance unless a new and unexpected result is produced. In reHarza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960) See MPEP 2144.04 VI B.

Claims 6 and 17:
Lu in view of Yin, Vin, Zheng, and Padmanabhan discloses the limitations shown above.
Lu discloses wherein the first set of nodes executes the electronic protocol by executing a smart contract on a blockchain and different blockchains. (See paragraph [0132], “[f]or example, the issuing bank 704 can send the cyphertext of the encrypted SBLC to the blockchain network 706 by calling a smart contract on the blockchain associated with the blockchain network 706. In the description below, it is assumed that interactions with the blockchain network 706 are performed by calling relevant smart contracts on the blockchain”; Fig. 12; and paragraphs [0168]-[0172].)
Claims 6 and 17 recite duplicated parts, such as a second electronic protocol, a third electronic protocol, a second smart contract, and a third smart contract. The mere duplication of parts has no patentable significance unless a new and unexpected result is produced. In reHarza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960) See MPEP 2144.04 VI B.

Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable
over Lu et al. (US 20210150515 A1) in view of Yin et al. (CN 111080449 A), and further
in view of Vo et al. (US 20190340267 A1), Zheng et al. (CN 109523380 A), Padmanabhan et al. (US 20200349564 A1), and Antonopoulos (“Mastering Bitcoin,” December 2014).
Claims 7 and 18:
Lu in view of Yin, Vo, Zheng, and Padmanabhan discloses the limitations shown above.
Lu discloses the following:
wherein a set of nodes: receives a subset of event attributes from other nodes; appends, to the blockchain maintained by the set of nodes, a first block instance comprising the subset of event attributes. (See Fig. 12; paragraphs [0168]-[0169], “[a]fter approval of the SBLC, the issuing bank 704 can finalize the SBLC source code, encrypt the SBLC source code, generate proofs, and include the encrypted SBLC and the proofs in a cross-chain request to the blockchain network 2 707…. After the blockchain nodes verify the proofs that prove the legitimacy of the SBLC, the blockchain nodes can perform consensus and store the encrypted SBLC in one or more blocks to be appended to the first blockchain.”)
receives another subset of event attributes from different set of nodes. (See Fig. 12; paragraphs [0171]-[0173], “[t]he beneficiary bank 708 can then confirm the acceptance of the SBLC at 1222 and request the blockchain network 2 707 to record the updated SBLC status on a second blockchain associated with the blockchain network 2 707 through consensus. In some embodiments, the beneficiary bank 708 can also send a cross-chain request to deliver the confirmation to the issuing bank 708…. At 1228, the blockchain nodes of the blockchain network 1 703 can verify the proof that the SBLC is issued on the second blockchain and deliver the verification result and the confirmation of acceptance to the issuing bank 704.”)
the set of nodes in response to determining (that the attributes are valid). (See Fig. 12; paragraphs [0173]-[0174], “[a]t 1228, the blockchain nodes of the blockchain network 1 703 can verify the proof that the SBLC is issued on the second blockchain and deliver the verification result and the confirmation of acceptance to the issuing bank 704…. At 1230, the issuing bank 704 can void the SBLC stored on the first blockchain in response to receiving the verification result and that the acceptance of the SBLC has been confirmed by the beneficiary bank 708…. At 1232, the blockchain network 1 703 can update the SBLC status on the first blockchain as ‘void.’”)
Yin discloses transmitting different subsets of event attributes to different sets of nodes that maintain different blockchains. (See paragraph 2 of Detailed Description, page 7, “Fig. 1 exemplarily shows a system architecture to which the method for providing a cross-chain transaction of a blockchain according to an embodiment of the present invention is applicable, where the system architecture may include N blockchain networks, a management node, and a client. Wherein N is greater than 1”; paragraph 3, page 8, “step 301, the management node receives a transaction to be executed sent by the client, and generates N preparation instructions corresponding to the N blockchain networks according to the transaction to be executed.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Yin in the Lu system. Moreover, in order to improve the practicality of the Lu system, one of ordinary skill in the art would have been motivated to transmit the different sets of event attributes to different sets of nodes associated with different blockchain networks, so that each of the blockchain networks only needs to store the related transaction attributes and that the cross-chain transaction can be processed and/or executed by different blockchain networks based on the corresponding subsets of the transaction attributes.
None of Lu, Yin, Vo, Zheng, and Padmanabhan explicitly discloses comparing a subset of event attributes with another subset of event attributes, and appending a block chain instance to a blockchain in response to determining a match between the subset of event attributes and the other subset of event attributes.
Antonopoulos discloses the following:
d.	comparing a subset of event attributes with another subset of event attributes. (See page 132; page 136; and pages 182-183.) 
e. 	appending a block chain instance to a blockchain in response to determining a match between the subset of event attributes and the other subset of event attributes. (See page 132; page 136; pages 182-183; page 184; and pages 201-202.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Antonopoulos in the Lu system as modified. Moreover, in order to improve the accuracy and security of the Lu system as modified, one of ordinary skill in the art would have been motivated to validate the pending transaction by comparing the received event attributes corresponding to the pending transaction and to include the validated transaction in the blockchain, so that the pending transaction can be verified by each node before it is broadcast to other nodes in the blockchain. This ensures that only valid transactions are propagated across the network, while invalid transactions are discarded at the first node that encounters them.

Claims 9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lu et al. (US 20210150515 A1) in view of Yin et al. (CN 111080449 A), and further in view of Vo et al. (US 20190340267 A1), Zheng et al. (CN 109523380 A), Antonopoulos (“Mastering Bitcoin,” December 2014), and Harris (US 20200051129 A1).
Claims 9 and 20:
Lu in view of Yin, Vo, and Zheng discloses the limitations shown above.
Lu discloses the following:
wherein the first computing device corresponds to a first set of nodes of the plurality of sets of nodes, the first set of nodes maintaining a first blockchain, and the second computing device corresponds to a second set of nodes, and wherein the first set of nodes. (See Fig. 12; paragraph [0164]; and paragraphs [0168]-[0172].) 
appending, to the first blockchain, a third blockchain instance comprising the first subset of the first set of event attributes corresponding to the pending event. (See Fig. 12; paragraphs [0168]-[0169], “[a]fter approval of the SBLC, the issuing bank 704 can finalize the SBLC source code, encrypt the SBLC source code, generate proofs, and include the encrypted SBLC and the proofs in a cross-chain request to the blockchain network 2 707…. After the nodes verify the proofs that prove the legitimacy of the SBLC, the blockchain nodes can perform consensus and store the encrypted SBLC in one or more blocks to be appended to the first blockchain.”)
receives, from the second set of nodes, a second subset of the second set of event attributes corresponding to the pending event. (See Fig. 12; paragraphs [0171]-[0173], “[t]he beneficiary bank 708 can then confirm the acceptance of the SBLC at 1222 and request the blockchain network 2 707 to record the updated SBLC status on a second blockchain associated with the blockchain network 2 707 through consensus. In some embodiments, the beneficiary bank 708 can also send a cross-chain request to deliver the confirmation to the issuing bank 708…. At 1228, the blockchain nodes of the blockchain network 1 703 can verify the proof that the SBLC is issued on the second blockchain and deliver the verification result and the confirmation of acceptance to the issuing bank 704.”)
None of Lu, Yin, Vo, and Zheng explicitly discloses the following:
retrieving the first subset of event attributes from the third block instance; 
comparing a first subset of event attributes with a second subset of event attributes; and 
responsive to determining the first subset of event attributes does not match the second subset of event attributes, generate an alert indicating the first subset of event attributes does not match the second subset of event attributes.
However, Antonopoulos discloses the following:
retrieving the first subset of event attributes from the third block instance; comparing a first subset of event attributes with a second subset of event attributes. (See page 132; page 136; and pages 182-183.)
responsive to determining the first subset of event attributes does not match the second subset of event attributes, generate a rejection alert. (See page 113, “[o]nce a bitcoin transaction is sent to any node connected to the bitcoin network, the transaction will be validated by that node…. If the transaction is invalid, the node will reject it and synchronously return a rejection message to the originator”; page 132; page 136; and pages 182-183, “[t]his ensures that only valid transactions are propagated across the network, while invalid transactions are discarded at the first node that encounters them.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Antonopoulos in the Lu system. Moreover, in order to improve the accuracy and security of the Lu system, one of ordinary skill in the art would have been motivated to validate the pending transaction by comparing the received event attributes corresponding to the pending transaction and to send a rejection message to the sender, so that the pending transaction can be verified by each node before it is broadcast to other nodes in the blockchain. This ensures that only valid transactions are propagated across the network and that the sender can be informed of the status of the transaction.
Harris, an analogous art of validating a transaction, discloses determining that a set of transaction attributes do not match another set of transaction attributes; and transmitting an alert to one of the computing devices indicating the two sets of transaction attribute do not match. (See paragraph [0044], “[a]ccording to the present example, when the value of an attribute of the transaction that is identified by the given record 402 does not match the value for the same attribute of the same transaction that is provided [or otherwise indicated] by the corresponding records 502, the given record 402 is said to contain an error”; paragraphs [0082]-[0083], “[i]n some implementations, the indication may include one or more of: an identifier of the record that contains the error [i.e., the selected record 402], an indication of the attribute whose value is incorrect, an indication of the correct value, at least some of the information obtained from the records 502 that is used in calculating the correct value, etc. In some implementations, the indication may be transmitted, at step 912, to the advertising platform 108 or another entity in order to prevent the advertiser from being overcharged as a result of the error.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Harris in the Lu system as modified. Moreover, in order to improve the accuracy of the Lu system as modified, one of ordinary skill in the art would have been motivated to compare two sets of transaction attributes one by one so as to locate the errors associated with unmatched attributes and to send an alert to the corresponding entities, so that the entities will be aware of the errors and prevent more incorrect actions.

Conclusion
The prior art, made of record and not relied upon, is considered pertinent to the applicant’s disclosure.
Madl et al. (US 20200252202 A1) discloses certifying a digital record by comparing information retrieved from different blockchain networks. 
Zhang et al. (US 20200278958 A1) discloses a method for processing cross-chain transactions.

The applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). The applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.

Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHUNLING DING, whose telephone number is (571)270-3605. The examiner can normally be reached 9:30 - 7:30 M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, an applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel, can be reached at 571-270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.




/CHUNLING DING/Examiner, Art Unit 3699          
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699