DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. In response to the Office action mailed on 6/18/2025, the applicants have filed a response: claims 1, 3, 5, 9, 10, 15, 16 and 22 - 24 have been amended. Claims 1 - 24 are pending.
Claim Objections
3. Claim 10 is objected to because of the following informalities: “the atomic swap system” in line 6 should refer to “the atomic swap engine” as recited in line 1. Appropriate correction is required.
4. Claim 17 is objected to because of the following informalities: the claim refers to “has value keys” in lines 3-4, but should refer to “hash value keys.” Appropriate correction is required.
Claim Rejections - 35 USC § 101
5. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
6. Claims 1 – 23 are directed to non-statutory subject matter. The claim do not fall within at least one of the four categories of patent eligible subject matter because independent claims 1 and 10 recite a distributed ledger technology (DLT) communication module embodied in software an atomic swap engine embodied in software, thus the claims amount to software per se. Dependent claims 2 – 9 and 11 – 23 depend from claim 1 and 10 and are thus rejected on the same basis.
7. Claims 1 – 9 are directed to an abstract idea without significantly more. Independent claim 1 recites a distributed ledger technology (DLT) communication
module embodied in software configured for connecting a DLT platform with a centralized global consensus module for consensus ordering and timestamping, the centralized global consensus module being configured to communicatively couple to the DLT platform and at least one other DLT platform, wherein the DLT communication module comprises: a state adopter module configured to retrieve and push to the centralized global consensus module transactions submitted to the DLT platform, the transactions at least referencing local states and/or local state changes of the DLT platform; and a status provider module configured to maintain and track the transactions
processed by the centralized global consensus module; wherein the state adopter module is configured to search in the status provider module for processed transactions containing any of the local states and/or local state changes referenced in the submitted transactions, and upon finding matching transactions notifying the DLT platform of the valid processing of the submitted transactions by the centralized global consensus module.
The limitations, as drafted, describe a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. The abstract idea limitations are “a status provider module configured to maintain and track the transaction…” and “wherein the state adopter module is configured to search in the status provider…by the centralized global consensus module” in Prong I step 2A. Other limitations including “A distributed ledger technology (DLT) communication module … configured for connecting …” and “a state adopter module configured to retrieve …” and are considered pre/post-activity solutions for receiving a state of performance information and performing an action which is merely an applied application which insignificantly amounts to a judicial exception. Thus, these claims are directing to abstract idea under 35 USC 101.
That is nothing in the claim elements preclude the steps from practically being performed in the mind. All of the non-abstract limitations are pre/post-activity solutions for getting/obtaining/manipulating/displaying data without significantly more. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the components in the determining step are recited at a high-level of generality (i.e., as a generic processor or a software module performing a generic computer function of receiving information, executing a function and making a decision) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Additionally, the steps of “A distributed ledger technology (DLT) communication module … configured for connecting …” and “a state adopter module configured to retrieve …” are pre/post-activity solutions as gathering/manipulating data that are insignificant under Prong II step 2A and 2B. See buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network) as noted in MPEP 2106.05(d)(II)(i). Accordingly, this additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a computer to perform the noted steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Additionally dependent claims 2 – 9 are similarly rejected as being directed to an abstract idea since these claims are either further detailing the abstract idea by analyzing/processing the data or the elements are insignificant. More specifically, the dependent claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception.
As per claim 2, wherein the state adopter module comprises a local state communication module configured to retrieve transactions submitted to the DLT platform is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 3, wherein the local communication module comprises a communication protocol library comprising a plurality of communication protocols, each associated with a DLT platform configuration is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 4, wherein the local communication module is configured to identify the communication configuration of the connected DLT platform and accordingly select a compatible communication protocol from the communication protocol library to enable the exchange of information is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 5, wherein the local communication module is configured to convert the format of information exchanged between the connected DLT platform and the centralized global consensus module is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 6, wherein the state adopter module comprises a DLT state checking module configured to search in the status provider module for historical transactions consuming any of the DLT local states associated with the submitted transaction, and to compare the unique consensus orders and timestamps of the any historical transaction identified as consuming any of the DLT local states to detect previous attempts for consuming the DLT local states associated with the submitted transaction is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 7, wherein the DLT state checking module is configured for retrieving information on consumed DLT local states from a local DLT consensus module is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 8, wherein the DLT state checking module is configured upon detecting that the local states associated with the submitted transaction have been consumed by a previous transaction, the state adopter module is configured to notify the distributed ledger platform to reject the submitted transaction, otherwise the state adopter module is configured to notify the DLT platform to validate the submitted transaction is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 9, wherein the status provider module is a mirroring computing node configured to push global DLT state changes of the centralized global consensus module to the state adopter module recites generic computer components for applying the abstract idea.
Claim Rejections - 35 USC § 103
8. 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.
9. 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.
10. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
11. Claims 1 and 2 are rejected under 35 U.S.C. 103 as being unpatentable over Hu et al. (U.S. Patent 10,404,473) (Hu hereinafter) in view of Patil et al. (U.S. Publication 2020/0226332) (Patil hereinafter).
12. As per claim 1, Hu discloses wherein the DLT communication module comprising: a state adopter module configured to retrieve and push to the global consensus module transactions submitted to the DLT platform, the transactions at least referencing local states and/or local state changes of the DLT platform; a status provider module configured to maintain and track the transactions processed by the global consensus module [“In an operation 404, method 400 may include fetching data stored in electronic memory and required to verify whether a transaction of the set of transactions and cryptographic signatures associated with the transaction are valid. In some implementations, the data stored in electronic memory may include data indicating the local state related to the transaction,” col. 10, lines 35 – 41]; and
wherein the state adopter module is configured to search in the status provider module for processed transactions containing any of the local states and/or local state changes referenced in the submitted transactions, and upon finding matching transactions notifying the DLT platform of the valid processing of the submitted transactions by the global consensus module [“In an operation 408, method 400 may include verifying cryptographic signatures associated with the transaction based on cryptographic operations performed by a set of cryptographic execution units operating in parallel. For example, the set of cryptographic execution units may perform cryptographic operations on one or more cached cryptographic signatures to verify whether the cryptographic signatures associated with the transaction are valid. In some implementations, verifying the cryptographic signatures associated with the transaction comprises identifying algorithmic parameters for the cryptographic signatures and dispatching cryptographic operations to the set of cryptographic execution units based on the identified algorithmic parameters. Each of the set of cryptographic execution units may be configured to perform one or more types of cryptographic operations. The cryptographic operations are performed to verify whether the cryptographic signatures are valid. Based on whether the cryptographic signatures are valid, an indication of whether the cryptographic signatures are valid or invalid may be cached in a signature validation result buffer,” col. 10, line 60 - col. 11, line 12; performing cryptographic operations (searching/finding) on one or more cached cryptographic signatures to verify whether the cryptographic signatures associated with the transaction (local states) are valid mapped to searching/finding the transactions that contain local state or local state changes].
Hu does not explicitly disclose but Patil discloses a centralized global consensus module a distributed ledger technology (DLT) communication module embodied in software for connecting a DLT platform with a centralized global consensus module for consensus ordering and timestamping, the centralized global consensus module being configured to communicatively couple to the DLT platform and at least one other DLT platform [“FIG. 2 is a block diagram of a system 2000 in accordance with one embodiment invention, coupled to multiple blockchain networks 2010. The system 2000 includes a user interface 2015 coupled to an integration server 2020. The integration server 2020 is coupled to the multiple blockchain networks 2010, a Central Control Center 2030, and multiple Distributed Data Centers 2050.sub.1, 2050.sub.2, . . . , 2050.sub.N (i.e., 2050.sub.i=1 to N). The Central Control Center 2030 includes a Request Handler 2035 and a Command Handling HSM 2040 configured to receive signatures from N operators OP1-OPN, for integer N.” ¶ 0041; Central Control Center mapped to centralized global consensus module; blockchain networks 2010 mapped to multiple DLT platforms, receipt of signatures suggests consensus; “A blockchain network includes a distributed data structure that includes an ordered chain of blocks. Each block stores a hash of its contents, timestamped copies of recent valid transactions, and a hash of the previous block. This ordered relationship ensures that blocks cannot be inserted into or deleted from the chain by a malicious actor,” ¶ 0005].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu and Patil available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu to include the capability of centrally managing blockchain access as taught by Patil, thereby providing a mechanism to enhance system security and efficiency by verifying distributed transaction states among multiple platforms in a single, centralized location/resource.
13. As per claim 2, Hu and Patil teach the DLT communication module according to claim 1. Hu further teaches wherein the state adopter module comprises a local state communication module configured to retrieve transactions submitted to the DLT platform [“In an operation 404, method 400 may include fetching data stored in electronic memory and required to verify whether a transaction of the set of transactions and cryptographic signatures associated with the transaction are valid. In some implementations, the data stored in electronic memory may include data indicating the local state related to the transaction,” col. 10, lines 35 – 41].
14. Claims 3 – 5 are rejected under 35 U.S.C. 103 as being unpatentable over Hu and Patil in further view of Zappier et al. (U.S. Publication 2018/0204213) (Zappier hereinafter).
15. As per claim 3, Hu and Patil teach the DLT communication module according to claim 2. Hu and Patil do not explicitly disclose but Zappier discloses wherein the local communication module comprises a communication protocol library comprising a plurality of communication protocols, each associated with a DLT platform configuration [“The blockchain dashboard 300 or “user block” may be configured to communicate with the various decentralized applications needed to provide the user 310 with access to the permissioned blockchain. In particular, the blockchain dashboard 300 may interface with the core block 244 application, which may be a cloud-based file system. The core block 244 comprises the protocols and smart contracts required by the various decentralized applications to execute their specific functions. For instance, the core block 244 may comprise blockchain-related protocols, libraries, database protocols, fileserver daemons, and the like,” ¶ 0046].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil and Zappier available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu and Patil to include the capability of facilitating secure communications as taught by Zappier, thereby providing a mechanism to enhance system security by utilizing established protocols for data transfers.
16. As per claim 4, Hu, Patil and Zappier teach the DLT communication module according to claim 3. Zappier further teaches wherein the local communication module is configured to identify the communication configuration of the connected DLT platform and accordingly select a compatible communication protocol from the communication protocol library to enable the exchange of information [“the client application 240 may comprise the blockchain dashboard which allows the user of the client system 101 to access the various decentralized applications that in turn allow the user to interact with the blockchain 241. The client application 240 may further be configured to access the core block server 140 to access the various protocols and smart contracts necessary for the decentralized applications to facilitate resource transfers,” ¶ 0041].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil and Zappier available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu and Patil to include the capability of facilitating secure communications as taught by Zappier, thereby providing a mechanism to enhance system security by utilizing established protocols for data transfers.
17. As per claim 5, Hu, Patil and Zappier teach the DLT communication module according to claim 4. Patil further teaches centralized global consensus module [“FIG. 2 is a block diagram of a system 2000 in accordance with one embodiment invention, coupled to multiple blockchain networks 2010. The system 2000 includes a user interface 2015 coupled to an integration server 2020. The integration server 2020 is coupled to the multiple blockchain networks 2010, a Central Control Center 2030, and multiple Distributed Data Centers 2050.sub.1, 2050.sub.2, . . . , 2050.sub.N (i.e., 2050.sub.i=1 to N). The Central Control Center 2030 includes a Request Handler 2035 and a Command Handling HSM 2040 configured to receive signatures from N operators OP1-OPN, for integer N.” ¶ 0041.
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu and Patil available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu to include the capability of centrally managing blockchain access as taught by Patil, thereby providing a mechanism to enhance system security and efficiency by verifying distributed transaction states among multiple platforms in a single, centralized location/resource.
Zappier further teaches wherein the local communication module is configured to convert the format of information exchanged between the connected DLT platform and the global consensus module [“the client application 240 may comprise the blockchain dashboard which allows the user of the client system 101 to access the various decentralized applications that in turn allow the user to interact with the blockchain 241. The client application 240 may further be configured to access the core block server 140 to access the various protocols and smart contracts necessary for the decentralized applications to facilitate resource transfers,” ¶ 0041; facilitating transfers using protocols suggests conversion].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil and Zappier available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu and Patil to include the capability of facilitating secure communications as taught by Zappier, thereby providing a mechanism to enhance system security by utilizing established protocols for data transfers.
18. Claims 6 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Hu and Patil in further view of Bentov et al. (U.S. Publication 2019/0156301) (Bentov hereinafter) (Identified by Applicant in IDS).
19. As per claim 6, Hu and Patil teach the DLT communication module according to claim 1. Hu and Patil do not explicitly discloses but Bentov discloses wherein the state adopter module comprises a DLT state checking module configured to search in the status provider module for historical transactions consuming any of the DLT local states associated with the submitted transaction, and to compare the unique consensus orders and timestamps of the any historical transaction identified as consuming any of the DLT local states to detect previous attempts for consuming the DLT local states associated with the submitted transaction [“Some embodiments are configured such that the exchange maintains, for each user, a UTXO that is spendable by the following script: (signed by the exchange's private key) OR (T expired AND signed by the user's private key). Also, for every time period t, we generate a large transaction signed by the exchange that consumes all the above - noted UTXOs and generates new ones with updated balances and updated timeout,” ¶ 0239].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil and Bentov available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu and Patil to include the capability of real-time cryptocurrency exchange management as taught by Bentov, thereby providing a mechanism to enhance system security by verifying distributed consensus states.
20. As per claim 7, Hu, Patil and Bentov teach the DLT communication module according to claim 6. Bentov further teaches wherein the DLT state checking module is configured for retrieving information on consumed DLT local states from a local DLT consensus module [“Some embodiments are configured such that the exchange maintains, for each user, a UTXO that is spendable by the following script: (signed by the exchange's private key) OR (T expired AND signed by the user's private key). Also, for every time period t, we generate a large transaction signed by the exchange that consumes all the above - noted UTXOs and generates new ones with updated balances and updated timeout,” ¶ 0239].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil and Bentov available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu and Patil to include the capability of real-time cryptocurrency exchange management as taught by Bentov, thereby providing a mechanism to enhance system security by verifying distributed consensus states.
21. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Hu, Patil and Bentov in further view of Padmanabhan (U.S. Publication 2020/0252205) (Padmanabhan hereinafter).
22. As per claim 8, Hu, Patil and Bentov teach the DLT communication module according to claim 6. Hu, Patil and Bentov do not explicitly disclose but Padmanabhan discloses wherein the DLT state checking module is configured upon detecting that the local states associated with the submitted transaction have been consumed by a previous transaction, the state adopter module is configured to notify the distributed ledger platform to reject the submitted transaction, otherwise the state adopter module is configured to notify the DLT platform to validate the submitted transaction [“issuing the decision by the AI model to accept or reject the transaction includes: extracting one or more parameters from the transaction received at the blockchain; consuming the one or more parameters as factors by the AI model to issue the decision to accept or reject the transaction; and further identifying within the new asset the one or more parameters consumed by the AI model in support of the AI model's decision to accept or reject the transaction,” ¶ 0634].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil, Bentov and Padmanabhan available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu, Patil and Bentov to include the capability of multi-tenant blockchain management as taught by Padmanabhan, thereby providing a mechanism to enhance system security by managing and reporting system states.
23. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Hu and Patil in further view of Madisetti et al. (U.S. Publication 2019/0018888) (Madisetti hereinafter).
24. As per claim 9, Hu and Patil teach the DLT communication module according to claim 1. Patil further teaches centralized global consensus module [“FIG. 2 is a block diagram of a system 2000 in accordance with one embodiment invention, coupled to multiple blockchain networks 2010. The system 2000 includes a user interface 2015 coupled to an integration server 2020. The integration server 2020 is coupled to the multiple blockchain networks 2010, a Central Control Center 2030, and multiple Distributed Data Centers 2050.sub.1, 2050.sub.2, . . . , 2050.sub.N (i.e., 2050.sub.i=1 to N). The Central Control Center 2030 includes a Request Handler 2035 and a Command Handling HSM 2040 configured to receive signatures from N operators OP1-OPN, for integer N.” ¶ 0041.
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu and Patil available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu to include the capability of centrally managing blockchain access as taught by Patil, thereby providing a mechanism to enhance system security and efficiency by verifying distributed transaction states among multiple platforms in a single, centralized location/resource.
Hu and Patil do not explicitly disclose but Madisetti discloses wherein the status provider module is a mirroring computing node configured to push global DLT state changes of the global consensus module to the state adopter module [“Referring now to FIG. 22, a method of smart contract mirroring, is described in more detail. The same smart contract (such as an ERC20 token contract) can be deployed on the private and public blockchain networks 1000, 1002. The smart contract 1006 on the private blockchain network 1000 is mirrored 1010 as the smart contract 1008 on the public blockchain network 1002 where the transactions on the private blockchain and periodically synchronized and checkpointed on the public blockchain network,” ¶ 0171].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil and Madisetti available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu and Patil to include the capability of blockchain management as taught by Madisetti, thereby providing a mechanism to enhance system security by mirroring system states.
25. Claims 10 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Hu and Patil in further view of Padmanabhan.
26. As per claim 24, Hu teaches validating at the global consensus module the atomic swap transactions; wherein processing and executing an atomic swap transaction comprising: locating and validating the digital records referenced in the atomic swap request in the corresponding initiator party DLT platform and collaborator party DLT platform; and executing the atomic swap transaction by assigning the digital records in the initiator DLT platform to the at least one collaborating party and the digital records in the collaborating DLT platform to the at last one initiator party, and locking the exchanged digital records in the corresponding initiator and collaborator DLT platforms [“In an operation 408, method 400 may include verifying cryptographic signatures associated with the transaction based on cryptographic operations performed by a set of cryptographic execution units operating in parallel. For example, the set of cryptographic execution units may perform cryptographic operations on one or more cached cryptographic signatures to verify whether the cryptographic signatures associated with the transaction are valid. In some implementations, verifying the cryptographic signatures associated with the transaction comprises identifying algorithmic parameters for the cryptographic signatures and dispatching cryptographic operations to the set of cryptographic execution units based on the identified algorithmic parameters. Each of the set of cryptographic execution units may be configured to perform one or more types of cryptographic operations. The cryptographic operations are performed to verify whether the cryptographic signatures are valid. Based on whether the cryptographic signatures are valid, an indication of whether the cryptographic signatures are valid or invalid may be cached in a signature validation result buffer,” col. 10, line 60 - col. 11, line 12]; and requesting the at least one initiator party DLT platform to push, via the corresponding DLT communication module, the DLT local state change introduced by the execution of the atomic swap transaction to the global consensus module [“In an operation 404, method 400 may include fetching data stored in electronic memory and required to verify whether a transaction of the set of transactions and cryptographic signatures associated with the transaction are valid. In some implementations, the data stored in electronic memory may include data indicating the local state related to the transaction,” col. 10, lines 35 – 41].
Hu does not explicitly disclose but Patil discloses a centralized global consensus module; and an atomic swap method for performing an atomic swap transaction for the exchange of digital records between at least one initiator party and at least one collaborator party, the digital records involved in the atomic swap transaction being stored in a plurality of corresponding distributed ledger technology (DLT) platforms respectively associated with the at least one initiator party and the at least one collaborator party, the atomic swap method comprising: communicatively coupling by means of at least one DLT communication module according to claim 1 each DLT platform participating in the atomic swap engine to a centralized global consensus module; and processing and executing atomic swap transaction requests received from at least one initiator party via a client application involving the exchange of digital records stored in at least one initiator party DLT platform and digital records stored in at least one collaborator party DLT platform [“FIG. 2 is a block diagram of a system 2000 in accordance with one embodiment invention, coupled to multiple blockchain networks 2010. The system 2000 includes a user interface 2015 coupled to an integration server 2020. The integration server 2020 is coupled to the multiple blockchain networks 2010, a Central Control Center 2030, and multiple Distributed Data Centers 2050.sub.1, 2050.sub.2, . . . , 2050.sub.N (i.e., 2050.sub.i=1 to N). The Central Control Center 2030 includes a Request Handler 2035 and a Command Handling HSM 2040 configured to receive signatures from N operators OP1-OPN, for integer N.” ¶ 0041; Central Control Center mapped to centralized global consensus module; blockchain networks 2010 mapped to multiple DLT platforms, receipt of signatures suggests consensus; “A blockchain network includes a distributed data structure that includes an ordered chain of blocks. Each block stores a hash of its contents, timestamped copies of recent valid transactions, and a hash of the previous block. This ordered relationship ensures that blocks cannot be inserted into or deleted from the chain by a malicious actor. ,” ¶ 0005].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu and Patil available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu to include the capability of centrally managing blockchain access as taught by Patil, thereby providing a mechanism to enhance system security and efficiency by verifying distributed transaction states among multiple platforms in a single, centralized location/resource.
Hu and Patil do not explicitly disclose but Padmanabhan discloses transferring to the at least one initiator party and at least one collaborator party a key to release the exchanged digital records in the corresponding DLT platforms [“The decentralized blockchain may use ad-hoc message passing and distributed networking. The blockchain network lacks centralized points of vulnerability that computer hackers may exploit. Likewise, it has no central point of failure. Blockchain security methods include the use of public-key cryptography. A public key is an address on the blockchain. Value tokens sent across the network are recorded as belonging to that address. A private key is like a password that gives its owner access to their digital assets or the means to otherwise interact with the various capabilities that blockchains support. Data stored on the block chain is generally considered incorruptible. This is where blockchain has its advantage,” ¶ 0084].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil and Padmanabhan available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu and Patil to include the capability of multi-tenant blockchain management as taught by Padmanabhan, thereby providing a mechanism to enhance system security by managing and reporting system states.
27. As per claim 10, it is a software claim having similar limitations as cited in claim 24. Thus, claim 10 is also rejected under the same rationale as cited in the rejection of claim 24 above.
28. As per claim 22, Hu, Patil and Padmanabhan teach an atomic swap engine according to claim 10. Hu further teaches wherein the centralized global consensus module is configured to submit each transaction for validation to the global committee selection module and record each valid transaction in a global distributed ledger platform [“In an operation 404, method 400 may include fetching data stored in electronic memory and required to verify whether a transaction of the set of transactions and cryptographic signatures associated with the transaction are valid. In some implementations, the data stored in electronic memory may include data indicating the local state related to the transaction,” col. 10, lines 35 – 41].
29. As per claim 23, Hu, Patil and Padmanabhan teach an atomic swap engine according to claim 12. Hu further teaches wherein the centralized global consensus module is configured to link local state changes of each connected DLT platform to the global state changes of the global distributed ledger platform [“if both the ledger reading set and the cryptographic signatures are valid, system 100 may be configured to write the transaction to the state cache and update the global state based on the transaction. In order to update the global state based on the transaction, the ledger writing set is applied to the global state. For example, if system 100 determines that both the ledger reading set and the cryptographic signatures are valid for a given transaction, a ledger writing set associated with that transaction cached in write set holding buffer 112 may be applied to the global state to update the global state based on the transaction,” col. 6, lines 1 – 12].
30. Claims 11 – 16 are rejected under 35 U.S.C. 103 as being unpatentable over Hu, Patil and Padmanabhan in further view of Olson (U.S. Patent 11,049,128) (Olson hereinafter).
31. As per claim 11, Hu, Patil and Padmanabhan teach an atomic swap engine according to claim 10. Hu, Patil and Padmanabhan do not explicitly disclose but Olson discloses wherein the atomic swap engine comprising a cryptographic module configured to anonymise the retrieved transactions [“any data for an attribute of the transaction information posted to a blockchain may be encrypted using encoder 212A, for example, to provide security and/or protect sensitive information. Data stored for these attributes may be quantitative (e.g., an amount) and/or qualitative (e.g., name of merchant),” col. 10, lines 44 – 49; providing security/protecting sensitive information mapped to anonymising].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil, Padmanabhan and Olson available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu, Patil and Padmanabhan to include the capability of protection of sensitive data as taught by Olson, thereby providing a mechanism to enhance system security by managing access to sensitive data.
32. As per claim 12, Hu, Patil, Padmanabhan and Olson teach an atomic swap engine according to claim 11. Olson further teaches wherein the cryptographic
module is configured to anonymize the retrieved transaction by removing and/or
obfuscating sensitive information attributed to a specific data subject [“any data for an attribute of the transaction information posted to a blockchain may be encrypted using encoder 212A, for example, to provide security and/or protect sensitive information. Data stored for these attributes may be quantitative (e.g., an amount) and/or qualitative (e.g., name of merchant),” col. 10, lines 44 – 49; qualitative data mapped to specific data subject].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil, Padmanabhan and Olson available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu, Patil and Padmanabhan to include the capability of protection of sensitive data as taught by Olson, thereby providing a mechanism to enhance system security by managing access to sensitive data.
33. As per claim 13, Hu, Patil, Padmanabhan and Olson teach an atomic swap engine according to claim 11. Olson further teaches wherein the cryptographic module is configured to hash and/or encrypt the retrieved transactions [“any data for an attribute of the transaction information posted to a blockchain may be encrypted using encoder 212A, for example, to provide security and/or protect sensitive information. Data stored for these attributes may be quantitative (e.g., an amount) and/or qualitative (e.g., name of merchant),” col. 10, lines 44 – 49].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil, Padmanabhan and Olson available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu, Patil and Padmanabhan to include the capability of protection of sensitive data as taught by Olson, thereby providing a mechanism to enhance system security by managing access to sensitive data.
34. As per claim 14, Hu, Patil, Padmanabhan and Olson teach an atomic swap engine according to claim 11. Hu further teaches wherein the connector module is configured to lock the exchanged digital records using a state hash value key generated by means of the cryptographic module from a hash function obtained from a state change of the at least one initiator DLT platform [“In an operation 408, method 400 may include verifying cryptographic signatures associated with the transaction based on cryptographic operations performed by a set of cryptographic execution units operating in parallel. For example, the set of cryptographic execution units may perform cryptographic operations on one or more cached cryptographic signatures to verify whether the cryptographic signatures associated with the transaction are valid. In some implementations, verifying the cryptographic signatures associated with the transaction comprises identifying algorithmic parameters for the cryptographic signatures and dispatching cryptographic operations to the set of cryptographic execution units based on the identified algorithmic parameters. Each of the set of cryptographic execution units may be configured to perform one or more types of cryptographic operations. The cryptographic operations are performed to verify whether the cryptographic signatures are valid. Based on whether the cryptographic signatures are valid, an indication of whether the cryptographic signatures are valid or invalid may be cached in a signature validation result buffer,” col. 10, line 60 - col. 11, line 12; “data buffer 206 may be configured to cache algorithm parameters required to verify a cryptographic signature, hash values (e.g., hash public key and hash private key), and other data written to a block comprising a set of transactions crypto engine 122 is tasked to verify. In various implementations, data buffer 206 may be configured to provide parameters to scheduler 204 to enable scheduler 204 to determine the type of algorithm required to authenticate a cryptographic signature,” col. 6, lines 53 - 60].
35. As per claim 15, Hu, Patil, Padmanabhan and Olson teach an atomic swap engine according to claim 14. Hu further teaches wherein the cryptographic module is configured to generate separate state hash value keys for the at least one initiator party and at least one collaborator party to unlock the respective swapped digital records [“data buffer 206 may be configured to cache algorithm parameters required to verify a cryptographic signature, hash values (e.g., hash public key and hash private key), and other data written to a block comprising a set of transactions crypto engine 122 is tasked to verify. In various implementations, data buffer 206 may be configured to provide parameters to scheduler 204 to enable scheduler 204 to determine the type of algorithm required to authenticate a cryptographic signature,” col. 6, lines 53 - 60].
36. As per claim 16, Hu, Patil, Padmanabhan and Olson teach an atomic swap engine according to claim 15. Hu further teaches wherein the initiator party key is generated based on the state hash value and a reference to the state changes of the centralized global consensus module distributed ledger platform [“data buffer 206 may be configured to cache algorithm parameters required to verify a cryptographic signature, hash values (e.g., hash public key and hash private key), and other data written to a block comprising a set of transactions crypto engine 122 is tasked to verify. In various implementations, data buffer 206 may be configured to provide parameters to scheduler 204 to enable scheduler 204 to determine the type of algorithm required to authenticate a cryptographic signature,” col. 6, lines 53 - 60].
37. Claims 17 – 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hu, Patil, Padmanabhan and Olson in further view of Love (U.S. Publication 2020/0051068) (Love hereinafter).
38. As per claim 17, Hu, Patil, Padmanabhan and Olson teach an atomic swap engine according to claim 11. Hu, Patil, Padmanabhan and Olson do not explicitly disclose but Love discloses wherein the connector module is communicatively coupled to an escrow module configured to lock the digital records involved in the atomic swap transaction using the generated state has value keys [“Once the PT is created, it is placed in escrow for claim by the purchaser, and a blockchain transactions is recorded noting the value of the PT and the hashed UserID connected to the PTs, and the ClaimStatus state variable is created as Unclaimed. In some embodiments, the PTs may be automatically recorded as claimed or held unclaimed until a certain criterion is meet such as the purchaser participating in a threshold number of transactions,” ¶ 0044; held unclaimed until criteria met mapped to locked].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil, Padmanabhan, Olson and Love available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu, Patil, Padmanabhan and Olson to include the capability conditional escrow management as taught by Love, thereby providing a mechanism to enhance system security by managing conditional access to sensitive data.
39. As per claim 18, Hu, Patil, Padmanabhan, Olson and Love teach an atomic swap engine according to claim 17. Love further teaches wherein the escrow module
comprises a smart contract programme operating on each connected DLT platform,
which is configured to lock the digital records with time- bounds using hash locks and
time locks generated from cryptographic hash functions and cryptographic signatures [“Once the PT is created, it is placed in escrow for claim by the purchaser, and a blockchain transactions is recorded noting the value of the PT and the hashed UserID connected to the PTs, and the ClaimStatus state variable is created as Unclaimed. In some embodiments, the PTs may be automatically recorded as claimed or held unclaimed until a certain criterion is meet such as the purchaser participating in a threshold number of transactions,” ¶ 0044; held unclaimed until criteria met duration mapped to time-bound].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil, Padmanabhan, Olson and Love available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu, Patil, Padmanabhan and Olson to include the capability conditional escrow management as taught by Love, thereby providing a mechanism to enhance system security by managing conditional access to sensitive data.
40. As per claim 19, Hu, Patil, Padmanabhan, Olson and Love teach an atomic swap engine according to claim 17. Love further teaches wherein the escrow module is configured to release the locked digital records upon certain conditions of the atomic swap execution being satisfied [“Once the PT is created, it is placed in escrow for claim by the purchaser, and a blockchain transactions is recorded noting the value of the PT and the hashed UserID connected to the PTs, and the ClaimStatus state variable is created as Unclaimed. In some embodiments, the PTs may be automatically recorded as claimed or held unclaimed until a certain criterion is meet such as the purchaser participating in a threshold number of transactions,” ¶ 0044; held unclaimed until criteria met duration mapped to time-bound].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil, Padmanabhan, Olson and Love available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu, Patil, Padmanabhan and Olson to include the capability conditional escrow management as taught by Love, thereby providing a mechanism to enhance system security by managing conditional access to sensitive data.
41. Claims 20 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Hu, Patil, Padmanabhan in further view of Zhuang (U.S. Publication 2018/0285412) (Zhuang hereinafter).
42. As per claim 20, Hu, Patil and Padmanabhan teach an atomic swap engine according to claim 10. Hu, Patil and Padmanabhan do not explicitly disclose but Zhuang discloses wherein the global consensus module comprises a global committee selection module configured for selecting Transaction checker (TC) nodes from connected DLT platform to form a set of global transaction consensus nodes participating in the validation, recording and tracking of state changes of the connected DLT platforms participating in the atomic swap transactions [“when the consensus results are stored into blocks of the blockchain, storage nodes may be selected in a random manner; or according to a correspondence relationship between consensus units and storage nodes, the consensus results are stored into blocks of nodes in the blockchain network corresponding to consensus units that generate the consensus results, which is not limited herein. Namely, a consensus unit can store consensus results generated by itself, store consensus results generated by other consensus units, or does not store consensus results with the consensus results stored to independent storage nodes,” ¶ 0091; selected consensus units mapped to TCs].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil, Padmanabhan and Zhuang available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu, Patil and Padmanabhan to include the capability of managing ledger consensus as taught by Zhuang, thereby providing a mechanism to enhance system security by managing transaction recording via multiple nodes.
43. As per claim 21, Hu, Patil, Padmanabhan and Zhuang teach an atomic swap engine according to claim 20. Zhuang further teaches wherein the global selection
module is configured to select the TC nodes based on a number of parameters that are
defined according to and satisfy fault tolerance principles or rational behaviour models [“the number of consensus units comprised in a consensus unit set is not limited herein. The numbers of voting nodes comprised in different consensus units may be the same or may be different. For example, if the consensus algorithm is the PBFT algorithm, one voting node in a consensus unit comprises one primary nodes and four secondary nodes. If the consensus algorithm is the proof of work mechanism, a consensus unit comprises at least one voting node. Therefore, the number of voting nodes in a consensus unit is not limited herein, which can be determined according to actual requirements of a consensus algorithm,” ¶ 0036; PBFT, or Practical Byzantine Fault Tolerance, mapped to selection of nodes via parameters defined to satisfy fault tolerant principles].
It would have been obvious to one of ordinary skill in the art, having the teachings of Hu, Patil, Padmanabhan and Zhuang available before the effective filing date of the claimed invention, to modify the capability of decentralized transaction verification as disclosed by Hu, Patil and Padmanabhan to include the capability of managing ledger consensus as taught by Zhuang, thereby providing a mechanism to enhance system security by managing transaction recording via multiple nodes.
Response to Arguments
Claim Objections
44. Applicant’s arguments have been fully considered and are persuasive. The objections have been withdrawn.
Claim Rejections - 35 USC § 101
45. Applicant's arguments have been fully considered but they are not persuasive.
46. Applicant refers to section 9 of the subject Office Action in arguing that claims 1, 10 and 24 are not directed to the abstract idea of a swap, but to solving a complex technical problem. However, as recited above, each limitation is analyzed individually as a whole and identified either as an abstract idea or an additional element. Solving a complex technical problem does not transform an abstract idea into an eligible improvement to computer network technology. The claims recite algorithm steps to be performed on a general purpose computing platform, as described in the instant specification on page 28.
Claim Rejections - 35 USC § 103
47. Applicant's arguments have been fully considered but they are not persuasive.
48. Applicant’s arguments with respect to Wang have been considered but are moot because the new ground of rejection does not rely on Wang.
49. Regarding Hu, the reference is cited in combination with Patil is teaching the amended claims, specifically with the centralized global consensus module. Additionally, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
50. In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the motivations to combine the cited references are recited above.
Conclusion
51. 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). 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.
52. Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM C WOOD whose telephone number is (571)272-5285. The examiner can normally be reached Monday - Friday, 8:00 am - 4:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, 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, Chat C Do can be reached at 571-272-3721. 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.
/WILLIAM C WOOD/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193