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 .
Claim Objections
2. Claims 9 and 11 are objected to because of the following informalities:
Claim 9 recites “iii. upon receipt … transmiting…”, wherein underlined word should be corrected to “transmitting”.
Claim 11 recites “submiting the geographic…”, wherein underlined word should be corrected to “submitting”.
Appropriate corrections are required.
Claim Rejections - 35 USC § 112
3. 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.
4. Claims 1-15 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.
Lack of antecedent basis
5. Claims 1 and 9 recite the limitation “the corresponding transaction” in paragraph starting with “i. a sender agent…”. There is insufficient antecedent basis for this limitation in the claim.
6. Claims 1 and 9 recite the limitation “the sending agent” in two places in paragraph starting with “ii. the sending agent…”. There is insufficient antecedent basis for this limitation in the claims.
Examiner suggests, perhaps the applicant was referring to “the sender agent”.
7. Claims 1 and 9 recite the limitations “the double-spending prevention subsystem” and “the unique owner of the corresponding digital asset” in paragraph starting with “ii. the sending agent…”. There is insufficient antecedent basis for these limitations in the claims.
8. Claim 1 recites the limitation “the modular double-spending prevention subsystem” in paragraph starting with “wherein…”. There is insufficient antecedent basis for this limitation in the claim.
9. Claim 8 recites the limitation “the resulting agents”. There is insufficient antecedent basis for this limitation in the claim.
Unclear Scope
10. Claim 9 recites “ii. the sending agent submits a certification request to the double-spending prevention subsystem and, if the sending agent is still the unique owner of the corresponding digital asset and either the sender agent or recipient agent receives a uniqueness attestation, for the transaction from the double-spending prevention subsystem”.
It is not clear what the sending agent trying to accomplish by submitting a certification request for the transaction from the double-spending prevention subsystem or something else, and if two conditions are met: i) the sending agent is still the unique owner of the corresponding digital asset, and ii) either the sender agent or recipient agent receives a uniqueness attestation.
11. Claim 9 recites “thereby executing transactions off-chain… and preventing double-spending prevention isolated to the proof aggregation layer”.
It is not clear whether claims are directed to preventing double-spending or preventing double-spending prevention.
12. “An essential purpose of patent examination is to fashion claims that are precise, clear, correct, and unambiguous. Only in this way can uncertainties of claim scope be removed, as much as possible, during the administrative process.” Zletz, 893 F.2d at 322, 13 USPQ2d at 1322. “For example, if the language of a claim, given its broadest reasonable interpretation, is such that a person of ordinary skill in the relevant art would read it with more than one reasonable interpretation, then a rejection under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph is appropriate.” MPEP 2173.02 I.
13. Claims 2-7 and 10-15 are rejected under the same rationale as claims 1 and 9 because claims 2-7 and 10-15 inherit the deficiencies of claims 1 and 9 respectively due to their dependency.
Claim Rejections - 35 USC §101
14. 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.
15. Claims 1-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
16. In the instant case, claims 1 and 9 are directed to a “system and method for secure, off-chain transactions”.
17. Claim 9 recites “processing asset transactions”. Specifically, claim recites (abstract ideas emphasized in bold) “a. including in each of a plurality of autonomous agents, which execute off-chain, an encapsulation of state representing at least one digital asset and being configured to process transaction requests that modify the agent state;
b. in a proof aggregation layer that is a modular component separate from transaction execution, preventing double spending of the digital assets by:
i. receiving requests to certify that a particular asset state has not been previously spent;
ii. generating uniqueness attestations certifying that each asset state is spent at most once; and
iii. providing said uniqueness attestations to the agents;
in which:
i. a sender agent, which intends to send one of the digital assets to a recipient agent, processes the corresponding transaction locally to generate a new state;
ii. the sending agent submits a certification request to the double-spending prevention subsystem and, if the sending agent is still the unique owner of the corresponding digital asset and either the sender agent or recipient agent receives a uniqueness attestation, for the transaction from the double-spending prevention subsystem;
iii. upon receipt of the uniqueness attestation, transmiting from the sender agent the new state and the uniqueness attestation, if obtained by sender, to the recipient agent;
iv. by the recipient agent, verifying both correctness of the transaction execution, and validity of the uniqueness attestation as required conditions for accepting the transaction;
thereby executing transactions off-chain at the agents independent of global consensus and shared state among all network participants, and preventing double-spending prevention isolated to the proof aggregation layer”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
18. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 9 such as “digital assets”, “a plurality of autonomous agents”, “execute off-chain”, “at least one digital asset”, “a proof aggregation layer”, “a modular component”, “a sender agent”, “a recipient agent”, and “the double-spending prevention subsystem” do no more than represent the use of a computer as a tool to perform an abstract idea. The additional elements do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, and therefore, neither improve computer functionality nor improve another technology or technical field. With respect to “receiving requests to certify that a particular asset state has not been previously spent”, “providing said uniqueness attestations to the agents”, and “transmiting from the sender agent the new state and the uniqueness attestation, if obtained by sender, to the recipient agent” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
19. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform processing asset transactions and/or generally link the abstract idea to a particular technological environment or field of use, they do not improve computer functionality or provide an improvement to another technology or technological field.
20. Hence, claim 9 is not patent eligible.
21. Claim 1 also recites “processing asset transactions”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
22. As in the case of claim 9, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as “a distributed processing system”, “digital assets”, “a plurality of autonomous agents”, “execute off-chain”, “at least one digital asset”, “a proof aggregation layer”, “a modular component”, “a sender agent”, “a recipient agent”, “the double-spending prevention subsystem”, and “the modular double-spending prevention subsystem” do no more than represent the use of a computer as a tool to perform an abstract idea. The additional elements do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, and therefore, neither improve computer functionality nor improve another technology or technical field. And, with respect to “receiving requests to certify that a particular asset state has not been previously spent”, “providing said uniqueness attestations to the agents”, and “transmits the new state and the uniqueness attestation, if obtained by sender or recipient agent, to the recipient agent” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
23. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform processing asset transactions and/or generally link the abstract idea to a particular technological environment or field of use, they do not improve computer functionality or provide an improvement to another technology or technological field.
24. Hence, claim 1 is not patent eligible.
25. The following dependent claims recent additional elements not addressed above:
claims 3 and 11 recite “a consensus layer”, “a plurality of validators”, “a decentralized trust anchor”, “a blockchain”, and “an authenticated data structure”;
claims 4 and 12 recite “a sparse Merkle tree (SMT)”, “a most recent checkpoint”, “a previous checkpoint”, “a leaf node”, and “a certified root of the SMT”;
claims 5 and 13 recite “a ZK-SNARK proof system with constant-size proofs” and “a ZK-STARK proof system with logarithmic-size proofs”;
claims 6 and 14 recite “a hierarchical sharded architecture”, “a plurality of nodes”, “a sub-tree of the authenticated data structure”, “keyspace”, and “a slice of the keyspace”;
claims 7 and 15 recite “a Proof of Work blockchain forming a trust anchor”, “a Byzantine Fault Tolerant (BFT) arrangement”, and “BFT blocks”; and
Claim 8 recites “the resulting agents”.
When considered individually, and as a whole, each of these additional elements amount to merely "apply it", as they are merely applying the abstract idea to the technical environment of the consensus layer, the plurality of validators, the decentralized trust anchor, the blockchain, the authenticated data structure, the sparse Merkle tree (SMT), the most recent checkpoint, the previous checkpoint, the leaf node, the certified root of the SMT, the ZK-SNARK proof system with constant-size proofs, the ZK-STARK proof system with logarithmic-size proofs, the hierarchical sharded architecture, the plurality of nodes, the sub-tree of the authenticated data structure, the keyspace, the slice of the keyspace, the Proof of Work blockchain forming the trust anchor, the Byzantine Fault Tolerant (BFT) arrangement, the BFT blocks, and the resulting agents.
26. Dependent claims 2-8 and 10-15 merely expand upon the abstract ideas of the independent claims and are therefore rejected under the same rationale as claims 1 and 9 respectively.
Conclusion of 35 USC §101
27. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
28. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
29. 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.
30. 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.
31. 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.
32. Claims 1-3, 7, 9-11, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US20200302409A1 to Hearn et al. in view of US20200052886A1 to Buldas et al.
33. As per claim 1:
Hearn et al. discloses the following limitations:
A distributed processing system for transactions of digital assets comprising: ([0026] “A method and system are provided to support a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain…Protocol flows can be developed for different types of transactions, such as a transaction to sell an asset from a selling party to a buying party, a transaction to support an interest rate swap, a transaction involving more than two parties, and so on…”)
a. a plurality of autonomous agents that execute off-chain, each agent including an encapsulation of state representing at least one digital asset and being configured to process transaction requests that modify the agent state ([0026] “…A protocol flow is computer code that controls the performance of a transaction by the party or parties to the transaction…”, [0027] “…The proposed transaction specifies input state, output state, and identification of a notary. The input state may specify the funds used to buy the asset, and the output state may specify that ownership of the asset has been transferred. The input state and the output state include contract code that is used to verify whether the transaction is valid…”, [0029] “…The output state of the notarized transaction can be used as an input state to a subsequent transaction, and the notarized transaction can be provided as evidence that the output state that is being used as an input state in a subsequent transaction is valid output of the notarized transaction…”)
[b. a proof] … a modular component separate from transaction execution and prevents double spending of the digital assets by: ([0040] “In some embodiments, a notary service of the distributed ledger system provides transaction ordering and timestamping services in addition to transaction verification and notarizing services. The notary service may be provided by a notary service that decides whether to notarize a transaction or a notary service that interfaces with other mistrusting notary services who use a consensus algorithm such as a Byzantine fault tolerance algorithm or a Raft consensus algorithm to decide whether to notarize a transaction…If a network has multiple notaries, then notary services can seamlessly be phased in or out, a notary service can be jurisdiction-specific to comply with jurisdictional regulations, notary services can compete based on availability and performance, and so on.”, [0043] “…The notary component stores an indication of each consumed state in the consumed state store to prevent double-spending of the consumed output state…”, [claim 42] “…The combination of digital signatures are digital signatures of participants in a distributed notary.”)
i. receiving requests to certify that a particular asset state has not been previously spent ([0048] “…In block 501, the component receives from the accepting party an accepted transaction that is to be notarized…”, [0028] “…The notary then determines whether the input state to the accepted transaction has been already consumed (e.g., spent by another transaction) …”)
ii. generating uniqueness attestations certifying that each asset state is spent at most once ([0028] “…The notary may maintain a consumed state storage to track the output states that have been consumed by transactions. If the input state has not been consumed, then the notary code marks the output state of the transaction that is the input state for the accepted transaction as now consumed and notarizes the accepted transaction by signing the accepted transaction with the signature of the notary to generate a notarized transaction…”, [0040] “…The notary services receive accepted transactions, verify whether the input states of the transactions have been consumed, and if they have not, sign the accepted transaction…”)
iii. providing said uniqueness attestations to the agents ([0028] “…The notary code then sends the notarized transaction to the originator code.”, [0048] “…In block 510, the component sends to the accepting party (and optionally to the proposing party) the notarized transaction and then completes.”)
in which: i. a sender agent, which intends to send one of the digital assets to a recipient agent, processes the corresponding transaction locally to generate a new state ([0047] “…In block 404, the component generates a proposed transaction that specifies the input states, the output states, and the identification of the notary. In block 405, the component signs the proposed transaction with the private key of the proposing party…”, [0027] “…Upon receiving the proposed transaction, the originator code verifies the proposed transaction by … executing the contract code of the input state and output state of the proposed transaction to determine whether the proposed transaction is valid according to the contract code…”)
ii. the sending agent submits a certification request to the double-spending prevention subsystem and, if the sending agent is still the unique owner of the corresponding digital asset, the proof aggregation layer generates a uniqueness attestation, for the transaction from the double-spending prevention subsystem ([0042] “…When accepted by all accepting parties, the proposing party submits accepted transaction A to a notary. The notary verifies the signatures of accepted transaction A timestamps accepted transaction A ensures that the input states have not yet been consumed, and notarizes the accepted transaction A by signing with the notary's private key to generate a notarized transaction A…”, [0048] “…In block 507, the component sends to the accepting party a failure notification indicating that the transaction cannot be notarized because at least one input state has been consumed and then completes…”)
iii. upon receipt of the uniqueness attestation the sender agent transmits the new state and the uniqueness attestation, if obtained by sender or recipient agent, to the recipient agent ([0042] “…The notary then sends the notarized transaction A to the proposing party, who records the notarized transaction A and forwards the notarized transaction A to the accepting parties, who each record the notarized transaction A.”, [0046] “…In block 307, the component sends the accepted transaction to the notary specified in the accepted transaction. In block 308, the component receives from the notary the notarized transaction. In block 309, the component sends to the proposing party the notarized transaction…”)
iv. the recipient agent verifies both correctness of the transaction execution, and validity of the uniqueness attestation as required conditions for accepting the transaction ([0042] “…Each accepting party verifies that transaction A has been signed by the proposing party and invokes the contract code of the input states and at least its output state to ensure that the proposed transaction complies with the terms of the contract…”, [0029] “…Upon receiving the notarized transaction, the responder code verifies that the notarized transaction has been signed by the notary and the originating party and records the notarized transaction in its ledger…”)
wherein transaction execution happens off-chain at the agents independent of global consensus and shared state among all network participants ([0030] “The distributed ledger system thus allows transactions to be proposed, accepted, and notarized by a notary and stored without the use of a blockchain ledger. In this way, the distributed ledger system can avoid the expense of the computational and storage resources needed to redundantly verify a transaction and store evidence on the many nodes of a blockchain distributed ledger.”, [0029] “… In this way, both the originator party and the responder party maintain a copy of the notarized transaction in their ledgers as evidence of the notarized transaction…”), and wherein double-spending prevention is isolated to the modular double-spending prevention subsystem ([0043] “…The notary component stores an indication of each consumed state in the consumed state store to prevent double-spending of the consumed output state…”, [0040] “…The notary service may be provided by a notary service that decides whether to notarize a transaction or a notary service that interfaces with other mistrusting notary services who use a consensus algorithm such as a Byzantine fault tolerance algorithm or a Raft consensus algorithm to decide whether to notarize a transaction…”)
Hearn et al. does not disclose, however, Buldas et al., as shown, teaches the following limitations:
b. a proof aggregation layer that is … ([0057] “S operates in rounds (that is, hash tree aggregation intervals) and also maintains a hash tree 220, in which there is one pre-assigned leaf for every signer client, indexed by j…”, [0045] “…embodiments use spent key counters both at the signer side and server side; and the server periodically creates Merkle trees on top of its counters (i) and input hashes (y); and publishes root hashes to a public repository.”, [0012] “…With the hash value published, any one of the N public keys can be shown to belong to the tree with a proof consisting of log₂N hash values, thus aggregating, that is, combining, N instances of a one-time scheme into an N-time scheme…”, [0049] “In an embodiment, pre-validation is done by the Repository, which may be implemented in a manner analogous to double-spending prevention performed by blockchains…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing forward security, non-repudiation of the origin via efficient revocation, is resistant to known attacks even by efficient quantum computers of Buldas et al. (‘886, [0028]) with the teaching of Hearn et al. for supporting a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain (‘409, [0026]) for providing a modular certification layer that aggregates the certification requests of each round into a single hash-tree root and returning per-request hash-chain proofs to the requesting agents (‘886, [0012], [0045], [0049], [0057]).
34. As per claim 2:
Hearn et al. does not disclose, however, Buldas et al., as shown, teaches the following limitations:
each agent is verifiable, uniquely addressable, self-authenticated, and executes in diverse execution environments without dependence on specific infrastructure ([0099] “…the signature methods described for the different embodiments are efficient enough that the Signer/Device may typically (but need not be) be smaller, with less computational power and/or storage capacity, than general-purpose computers such as laptops, network servers, etc., for example, the Signer/Device D could be a tablet computer, smart phone, or other smart device configured to request signatures for data.”, [0057] “S operates in rounds (that is, hash tree aggregation intervals) and also maintains a hash tree 220, in which there is one pre-assigned leaf for every signer client, indexed by j…”)
agents interact by synchronizing provably unique state histories independent of any requirement for global state consensus ([0087]-[0088] “2. Maintains cryptographic links between roots; and 3. Makes roots available.”, [0093] “Checks if rt is present in the blockchain for round t.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing forward security, non-repudiation of the origin via efficient revocation, is resistant to known attacks even by efficient quantum computers of Buldas et al. (‘886, [0028]) with the teaching of Hearn et al. for supporting a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain (‘409, [0026]) for verifying via its public key p, authenticating every request with its own pre-generated keys, and executing diverse execution environments and providing a modular certification layer that aggregates the certification requests of each round into a single hash-tree root and returning per-request hash-chain proofs to the requesting agents (‘886, [0057], [0087]-[0088], [0093], [0099]).
Claim 10 is rejected using the same rationale that was used for the rejection of claim 2.
35. As per claim 3:
Hearn et al. does not disclose, however, Buldas et al., as shown, teaches the following limitations:
further comprising a consensus layer comprising a plurality of validators and providing a decentralized trust anchor, said consensus layer maintaining a blockchain and certifying state transitions of the proof aggregation layer ([0049] “…The Repository can be implemented as a Byzantine fault tolerant distributed state machine, which eliminates the need to trust a single party…”, [0059] “…First (depicted as layer Rv) it verifies the operation of S and after successful verification it commits the root value R to an append-only data structure, such as blockchain 330, which may be public…”, [0049] “…The Repository may then publish a root hash only after validating the correct operation of the Server(s) round…”)
in which: each certification request comprises a request identifier, a payload, and an authenticator ([claim 1] “…receiving at a signing server a query for a signature of a message said request comprising a randomizing function of the message and a current key, said key being one of a plurality of pre-generated keys…”, [0057] “…A hash tree leaf lt=(it; yt) for round t contains the tuple of the counter value it and the current input query yt from S…”)
the proof aggregation layer is further configured to: insert each certification request into an authenticated data structure at a deterministic position based on the request identifier ([0094] “For proof of correct operation, the Server may maintain an internal Merkle tree, in which every client (Signer) has a pre-assigned leaf position; its request hash (y) and counter value (i) are located in this particular position…”)
generate a cryptographic non-deletion proof demonstrating that a batch of insertions did not delete or modify existing entries ([0057] “…S is allowed to strictly increment i and for every changed leaf it presents a Proof P of correct operation to R.”, [0058] “A Proof may comprise the value of the leaf in the previous round and the hash chain leading to the root of previous round, previously published by R, and the leaf value at the current round, accomplished with a hash chain to the newly computed root of current round.”, [0060]-[0063] “Repository R then performs the following checks for each changed leaf. it−1+1=it, All presented hash-chains are correct and consistent with each other. Remaining leaves without a proof are not changed.”, [0086] “1. Verifies the validity of every change in the server’s hash tree. If a sibling hash in any hash chain has changed, then there must be a proof showing that this change was caused by a valid change of a leaf. Key indexes were only incremented.”)
submit the cryptographic non-deletion proof and a state root to the consensus layer (200) for certification ([0082] “4. Submits rt to repository R together with validity proof of every changed leaf:”, [claim 9] “…verifying correct operation of the signing server before registering the root value in the repository, and if the correct operation of the signing server is verified, returning to the signing server confirmation of registration.”)
generate uniqueness proofs for individual state transitions, each uniqueness proof comprising a proof of inclusion of the state transition in a certified state of the authenticated data structure ([claim 1] “…returning to the signing entity parameters of a first hash chain corresponding to a path through the hash tree from a hash of the query and a current counter value up to the root value of the hash tree for the round during which the request is received… incrementing the counter associated with the signing entity, whereby the current key is made unusable for signing in subsequent rounds.”, [0093] “Checks if rt is present in the blockchain for round t.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing forward security, non-repudiation of the origin via efficient revocation, is resistant to known attacks even by efficient quantum computers of Buldas et al. (‘886, [0028]) with the teaching of Hearn et al. for supporting a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain (‘409, [0026]) for distributing state machine comprising a plurality of parties (e.g., validators), maintaining an append-only blockchain and certifying the state transitions of the aggregation server, determining by the requesting client’s identity computed from the request identifier, generating cryptographic proofs of correct operation covering the batch of leaf changes, submitting its state root together with the proofs of correct (non-destructive) operation to the consensus layer (e.g., BFT repository), and generating a uniqueness proof comprising a proof of inclusion (i. e., the hash chain from the request leaf to the round root) while the counter mechanism guarantees each key state is used at most once (‘886, [0049], [0057]-[0059], [0063], [0086], [0094], [claim 1], [claim 9]).
Claim 11 is rejected using the same rationale that was used for the rejection of claim 3.
36. As per claim 7:
Hearn et al. does not disclose, however, Buldas et al., as shown, teaches the following limitations:
in which the consensus layer comprises: a Proof of Work blockchain forming a trust anchor ([0022] “One current point of dispute when it comes to the concept of a “blockchain” is whether, by definition, any entity may be allowed to submit blocks to and verify blocks in the blockchain, possibly only upon meeting some proof-of-work (such as Bitcoin’s “mining”), or proof-of-stake requirement…”, [0059] “…it commits the root value R to an append-only data structure, such as blockchain 330, which may be public…”)
a Byzantine Fault Tolerant (BFT) arrangement configured to provide deterministic finality ([0049] “…The Repository can be implemented as a Byzantine fault tolerant distributed state machine, which eliminates the need to trust a single party…”, [0084] “Note that the signature is composed and sent to verifier V only after the verification of rt…”)
a certification mechanism wherein the BFT arrangement certifies state transitions of the proof aggregation layer by including state roots in BFT blocks ([0064] “If all checks pass, then R (the last, that is, most recent, block) is appended to the repository…”, [0059] “…it commits the root value R to an append-only data structure, such as blockchain 330…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing forward security, non-repudiation of the origin via efficient revocation, is resistant to known attacks even by efficient quantum computers of Buldas et al. (‘886, [0028]) with the teaching of Hearn et al. for supporting a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain (‘409, [0026]) for stating that the blockchains may be open “upon meeting some proof-of-work, anchoring blockchains includes the Proof of Work species forming the trust anchor, wherein BFT distributed state machine and its round-by-round commitment verifying roots of the append-only structure is valid only upon confirmed registration, appending by the BFT repository each verified root as “the last, that is, most recent, block” (‘886, [0022], [0049], [0059], [0064], [0084]).
Claim 15 is rejected using the same rationale that was used for the rejection of claim 7.
37. As per claim 9:
Hearn et al. discloses the following limitations:
A method for distributed processing of transactions of digital assets comprising: ([0026] “A method and system are provided to support a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain…Protocol flows can be developed for different types of transactions, such as a transaction to sell an asset from a selling party to a buying party, a transaction to support an interest rate swap, a transaction involving more than two parties, and so on…”)
a. including in each of a plurality of autonomous agents, which execute off-chain, an encapsulation of state representing at least one digital asset and being configured to process transaction requests that modify the agent state ([0026] “…A protocol flow is computer code that controls the performance of a transaction by the party or parties to the transaction…”, [0027] “…The proposed transaction specifies input state, output state, and identification of a notary. The input state may specify the funds used to buy the asset, and the output state may specify that ownership of the asset has been transferred. The input state and the output state include contract code that is used to verify whether the transaction is valid…”, [0029] “…The output state of the notarized transaction can be used as an input state to a subsequent transaction, and the notarized transaction can be provided as evidence that the output state that is being used as an input state in a subsequent transaction is valid output of the notarized transaction…”)
[b. in a proof] … a modular component separate from transaction execution, preventing double spending of the digital assets by: ([0040] “In some embodiments, a notary service of the distributed ledger system provides transaction ordering and timestamping services in addition to transaction verification and notarizing services. The notary service may be provided by a notary service that decides whether to notarize a transaction or a notary service that interfaces with other mistrusting notary services who use a consensus algorithm such as a Byzantine fault tolerance algorithm or a Raft consensus algorithm to decide whether to notarize a transaction…If a network has multiple notaries, then notary services can seamlessly be phased in or out, a notary service can be jurisdiction-specific to comply with jurisdictional regulations, notary services can compete based on availability and performance, and so on.”, [0043] “…The notary component stores an indication of each consumed state in the consumed state store to prevent double-spending of the consumed output state…”, [claim 42] “…The combination of digital signatures are digital signatures of participants in a distributed notary.”)
i. receiving requests to certify that a particular asset state has not been previously spent ([0048] “…In block 501, the component receives from the accepting party an accepted transaction that is to be notarized…”, [0028] “…The notary then determines whether the input state to the accepted transaction has been already consumed (e.g., spent by another transaction) …”)
ii. generating uniqueness attestations certifying that each asset state is spent at most once ([0028] “…The notary may maintain a consumed state storage to track the output states that have been consumed by transactions. If the input state has not been consumed, then the notary code marks the output state of the transaction that is the input state for the accepted transaction as now consumed and notarizes the accepted transaction by signing the accepted transaction with the signature of the notary to generate a notarized transaction…”, [0040] “…The notary services receive accepted transactions, verify whether the input states of the transactions have been consumed, and if they have not, sign the accepted transaction…”)
iii. providing said uniqueness attestations to the agents ([0028] “…The notary code then sends the notarized transaction to the originator code.”, [0048] “…In block 510, the component sends to the accepting party (and optionally to the proposing party) the notarized transaction and then completes.”)
in which: i. a sender agent, which intends to send one of the digital assets to a recipient agent, processes the corresponding transaction locally to generate a new state ([0047] “…In block 404, the component generates a proposed transaction that specifies the input states, the output states, and the identification of the notary. In block 405, the component signs the proposed transaction with the private key of the proposing party…”, [0027] “…Upon receiving the proposed transaction, the originator code verifies the proposed transaction by … executing the contract code of the input state and output state of the proposed transaction to determine whether the proposed transaction is valid according to the contract code…”)
ii. the sending agent submits a certification request to the double-spending prevention subsystem and, if the sending agent is still the unique owner of the corresponding digital asset and either the sender agent or recipient agent receives a uniqueness attestation, for the transaction from the double-spending prevention subsystem ([0042] “…When accepted by all accepting parties, the proposing party submits accepted transaction A to a notary. The notary verifies the signatures of accepted transaction A timestamps accepted transaction A ensures that the input states have not yet been consumed, and notarizes the accepted transaction A by signing with the notary's private key to generate a notarized transaction A…”, [0048] “…In block 507, the component sends to the accepting party a failure notification indicating that the transaction cannot be notarized because at least one input state has been consumed and then completes…”)
iii. upon receipt of the uniqueness attestation, transmiting from the sender agent the new state and the uniqueness attestation, if obtained by sender, to the recipient agent ([0042] “…The notary then sends the notarized transaction A to the proposing party, who records the notarized transaction A and forwards the notarized transaction A to the accepting parties, who each record the notarized transaction A.”, [0046] “…In block 307, the component sends the accepted transaction to the notary specified in the accepted transaction. In block 308, the component receives from the notary the notarized transaction. In block 309, the component sends to the proposing party the notarized transaction…”)
iv. by the recipient agent, verifying both correctness of the transaction execution, and validity of the uniqueness attestation as required conditions for accepting the transaction ([0042] “…Each accepting party verifies that transaction A has been signed by the proposing party and invokes the contract code of the input states and at least its output state to ensure that the proposed transaction complies with the terms of the contract…”, [0029] “…Upon receiving the notarized transaction, the responder code verifies that the notarized transaction has been signed by the notary and the originating party and records the notarized transaction in its ledger…”)
thereby executing transactions off-chain at the agents independent of global consensus and shared state among all network participants ([0030] “The distributed ledger system thus allows transactions to be proposed, accepted, and notarized by a notary and stored without the use of a blockchain ledger. In this way, the distributed ledger system can avoid the expense of the computational and storage resources needed to redundantly verify a transaction and store evidence on the many nodes of a blockchain distributed ledger.”, [0029] “… In this way, both the originator party and the responder party maintain a copy of the notarized transaction in their ledgers as evidence of the notarized transaction…”), and preventing double-spending prevention isolated to the proof aggregation layer ([0043] “…The notary component stores an indication of each consumed state in the consumed state store to prevent double-spending of the consumed output state…”, [0040] “…The notary service may be provided by a notary service that decides whether to notarize a transaction or a notary service that interfaces with other mistrusting notary services who use a consensus algorithm such as a Byzantine fault tolerance algorithm or a Raft consensus algorithm to decide whether to notarize a transaction…”)
Hearn et al. does not disclose, however, Buldas et al., as shown, teaches the following limitations:
b. in a proof aggregation layer that is … ([0057] “S operates in rounds (that is, hash tree aggregation intervals) and also maintains a hash tree 220, in which there is one pre-assigned leaf for every signer client, indexed by j…”, [0045] “…embodiments use spent key counters both at the signer side and server side; and the server periodically creates Merkle trees on top of its counters (i) and input hashes (y); and publishes root hashes to a public repository.”, [0012] “…With the hash value published, any one of the N public keys can be shown to belong to the tree with a proof consisting of log₂N hash values, thus aggregating, that is, combining, N instances of a one-time scheme into an N-time scheme…”, [0049] “In an embodiment, pre-validation is done by the Repository, which may be implemented in a manner analogous to double-spending prevention performed by blockchains…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing forward security, non-repudiation of the origin via efficient revocation, is resistant to known attacks even by efficient quantum computers of Buldas et al. (‘886, [0028]) with the teaching of Hearn et al. for supporting a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain (‘409, [0026]) for providing a modular certification layer that aggregates the certification requests of each round into a single hash-tree root and returning per-request hash-chain proofs to the requesting agents (‘886, [0012], [0045], [0049], [0057]).
38. Claims 4-6 and 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over US20200302409A1 to Hearn et al. in view of US20200052886A1 to Buldas et al. and US20210067330A1 to Rasmussen.
39. As per claim 4:
Neither Hearn et al. nor Buldas et al. disclose, however, Rasmussen, as shown, teaches the following limitations:
in which: the authenticated data structure is a sparse Merkle tree (SMT) ([0014] “…the invention relates to a computer-implemented method for processing sets of data for storing and keeping track of the same in a specific network, the method implementing a Sparsed Merkle tree…”, [0012] “…The Sparsed Merkle tree is similar to the Merkle tree, but the contained data is indexed, and each data point is placed at the leaf corresponding to the datapoint’s index…”)
the uniqueness proof for a state transition comprises: the cryptographic proof of non-deletion provided as a zero-knowledge proof at a most recent checkpoint, demonstrating that all insertions from a previous checkpoint to the most recent checkpoint did not delete or modify existing entries ([0074] “…each transaction is stored in the DART system as a distribute hash-table using a crypto-graphic hash of the transaction T data. This means that each transaction is identified by a unique hash value h. The transaction is put into a table order via the numerical value of the hash.”, [0070] “…the invention aims at efficiently removing and adding transactions in a secure and distribute manner. More generally the invention relates to a CRUD (create, read, update, delete) DHT (Distribute Hash Table) system.”)
at least one proof of non-inclusion for the request identifier for all rounds from the most recent checkpoint to a round immediately preceding the state transition, demonstrating that the state had not been previously spent ([0011] “The Merkle tree is however lacking the possibility to prove that an item is not part of the tree. This is generally called the Proving Non-Inclusion.”, [0012] “One solution provided in the prior art is using Sparsed Merkle trees.”)
a proof of inclusion for the state transition in a current round, comprising a hash chain from a leaf node to a certified root of the SMT ([0009] “…with H(TS) and H (H(TX) ∥ H(TZ)), it is easy to recompute the original root hash and prove that TA is part of the tree…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing forward security, non-repudiation of the origin via efficient revocation, is resistant to known attacks even by efficient quantum computers of Buldas et al. (‘886, [0028]) and a method for improving the efficiency of the processing of the information on the transactions and, in particular, its storage in a specific database of Rasmussen (‘330, [0013] with the teaching of Hearn et al. for supporting a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain (‘409, [0026]) for providing the authenticated data structure (i.e., a sparse Merkle tree) with indexed leaf placement, applied to transaction data, demonstrating that the state had not been previously spent (i.e., at least one proof of non-inclusion for the request identifier), identifying each transaction by a unique hash value, adding transactions in a secure and distribute manner, providing possibility to prove that an item is not part of the tree, and redundantly maintaining within the system (e.g., the section roots and the global root (“bullseye”)), managing more than Q nodes to keep redundancy and security of the data (‘330, [0009], [0011]-[0012], [0014], [0070]).
Claim 12 is rejected using the same rationale that was used for the rejection of claim 4.
40. As per claim 5:
Hearn et al. does not disclose, however, Buldas et al., as shown, teaches the following limitations:
in which the cryptographic proof of non-deletion is generated using one of: a hash chain-based proof having linear size; or a ZK-SNARK proof system with constant-size proofs, or a ZK-STARK proof system with logarithmic-size proofs ([0095] “The proof of correct operation can be constructed either iteratively, by generating hash chains before and after each leaf change, or in batches, taking hash chains before a round, applying all changes to hash tree leaves, generating the final Merkle tree, and then generating ‘after’-hash chains for each changed leaf…”)
the zero-knowledge proof thereby demonstrating correct execution of a non-deletion verification algorithm without revealing the contents of an insertion batch ([0054] “…Given the nature of cryptographic hash functions, what gets input into the KSI system, and thus ultimately into the calendar blockchain, cannot be reconstructed from the hash, or from what is entered into the calendar blockchain.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing forward security, non-repudiation of the origin via efficient revocation, is resistant to known attacks even by efficient quantum computers of Buldas et al. (‘886, [0028]) with the teaching of Hearn et al. for supporting a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain (‘409, [0026]) for generating a correct-operation (i.e., a non-deletion proof) as a hash chain-based proof, performing verification over hashes from which the underlying messages cannot be reconstructed, and the proof is not a zero-knowledge proof of execution of a verification algorithm, wherein counters and query hashes are visible to the repository (‘886, [0054], [0095]).
Claim 13 is rejected using the same rationale that was used for the rejection of claim 5.
41. As per claim 6:
Neither Hearn et al. nor Buldas et al. disclose, however, Rasmussen, as shown, teaches the following limitations:
in which the proof aggregation layer has a hierarchical sharded architecture comprising a plurality of nodes, each node operating a sub-tree of the authenticated data structure ([0116] “… ‘sSMT’ refer to sector Merkle trees. ‘cSMT’ refer to central Merkle trees. ‘sH’ refer to Sector Hash. ‘be’ refer to a bullseye.”, [0110] “The hash-table is distributed between the computer nodes connected via a network, where each node manages a sample of sections called a DART angle.”)
and is organized into shards based on keyspace partitioning, … and each shard handles a slice of the keyspace ([0083] “…the hash-table is divided … into sections S. Each section contains an ordered list of hash-values within a limited range…”, [0115] “Each node must maintain the database sections within nodes section angle, this means adding and removing the transaction and update the Merkle-Tree root of the section…”, [0114] “A section is to be managed by more than Q nodes to keep redundancy and security of the data.”)
wherein leaf positions are deterministically computed from request identifiers ([0012] “…each data point is placed at the leaf corresponding to the datapoint’s index…”, [0074] “…each transaction is identified by a unique hash value h. The transaction is put into a table order via the numerical value of the hash.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing forward security, non-repudiation of the origin via efficient revocation, is resistant to known attacks even by efficient quantum computers of Buldas et al. (‘886, [0028]) and a method for improving the efficiency of the processing of the information on the transactions and, in particular, its storage in a specific database of Rasmussen (‘330, [0013] with the teaching of Hearn et al. for supporting a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain (‘409, [0026]) for having a hierarchical sharded architecture (e.g., a plurality of computer nodes, each operating its own sector sub-trees (sector SMTs) of the one overall sparse Merkle tree, organizing by keyspace partitioning (i.e., the identifier hash) divided into sections (i.e., angles of the circular keyspace), and computing from the entries’ unique identifiers (hash values decomposed into rim-key indices) (‘330, [0012], [0074], [0110], [0114]-[0116]).
Claim 14 is rejected using the same rationale that was used for the rejection of claim 6.
42. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over US20200302409A1 to Hearn et al. in view of US20200052886A1 to Buldas et al. and US20200202350A1 to Chan et al.
43. As per claim 8:
Neither Hearn et al. nor Buldas et al. disclose, however, Chan et al., as shown, teaches the following limitations:
in which each agent is configured to implement programmability through predicates, the predicates comprising functions returning Boolean values that control state transitions, the predicates including at least one of: ([0020] “When the verifying blockchain node combines the locking script and the unlocking script and executes the combination, the result after execution may either be ‘TRUE’ or ‘FALSE’…”, [0021] “If the verifying blockchain node combines the locking script and the unlocking script, executes the combination, and the result is TRUE…”, [0328] “In embodiments, the set of state rules 2206 includes a state-transaction matrix that can be represented by a constraint on the unlocking transaction 2204 imposed by a locking script. In such embodiments, the constraint might be parameterised by the current state and the input from which the next state is determined…”)
an ownership predicate controlling transfer of ownership, wherein the ownership predicate verifies authentication credentials of a party requesting a state transition ([0224] “OP_CHECKSIG, which pops two items from the stack, using the first as a public key and the second as a signature, checks whether the popped signature is a valid signature and, if valid, pushes 1 (TRUE) onto the stack, otherwise pushes 0 (FALSE) onto the stack.”, [0024] “…the locking script might be ‘Anyone is free to point to this transaction output—and thereby unlock all of its stated value—if they can supply sufficient information to prove that they know Bob’s private key’…”)
a data predicate controlling updates to agent data ([0328] “…The constraint can include checks to ensure that the unlocking transaction 2204 includes an output that includes the next state value in a particular field.”, [0278] “…The locking script can require different characteristics of different unlocking transaction outputs, such as by requiring that Vout[0] of the unlocking transaction include certain data and script elements and that Vout[1] of the unlocking transaction include certain other data and other script elements.”)
a spawn predicate controlling creation of new agents by the agent, wherein the spawn predicate evaluates conditions for spawning and initializes a genesis state of spawned agents ([0083] “The permitted state machine state transitions might include a forking transition from one initial state to two subsequent states by creating, for the spending transaction, a first transaction output that corresponds to a first subsequent state …… inserting, into the first transaction output of the spending transaction, a third set of script elements, wherein the third set of script elements are part of a first locking script constraining the first subsequent transaction to take on the first subsequent state…”)
a split predicate controlling division of the agent into multiple agents, wherein the split predicate determines how state is partitioned among the resulting agents ([0032] “…Similarly, a transaction may subdivide and/or combine those multiple inputs to produce one or more outputs so that, for example, the number of inputs and the number of outputs may be different…”, [0041] “…the method comprises: determining a first set of constraints on a first spending transaction output; [determining a second set of] constraints on a second spending transaction output; creating an [initial locking] script that includes the first set of constraints and the second set of constraints…”, [0084] “The first locking script can constrain the first subsequent transaction to have a first state and the second locking script can constrain the second subsequent transaction to have a second state…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for providing forward security, non-repudiation of the origin via efficient revocation, is resistant to known attacks even by efficient quantum computers of Buldas et al. (‘886, [0028]) and a method for determining a spending transaction constraint that constrains a spending transaction to include a spending transaction input that references a previous transaction output of Chan et al. (‘350, [0054] with the teaching of Hearn et al. for supporting a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain (‘409, [0026]) for locking script embedding the state and the state rules and whose execution returning TRUE/FALSE (i.e., a Boolean) result that controls whether the state transition occurs, controlling by the locking script transfer of ownership and verifying the authentication credentials (signature against public key, evaluating to TRUE/FALSE) of the party requesting the state transition, controlling updates to the state data (i.e., verifying that the successor state carries the permitted next-state value and prescribed data in particular fields), controlling by initial locking script the division of one state object into multiple resulting state objects and determining how value is partitioned among them, including its state, value, and script content (‘350, [0020]-[0021], [0024], [0032], [0041], [0083]-[0084], [0224], [0278], [0328]).
Conclusion
44. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20230093581A1 – Fritzhanns et al. – Discloses a method for directly transmitting electronic coin datasets between terminals in order to make a payment in a payment system, wherein a first terminal has at least one electronic coin dataset, and the at least one electronic coin dataset has a monetary value and a concealment value as coin data set elements.
US20190139037A1 – Khalil et al. – Discloses a system, method, method for manufacturing, apparatus, and computer-readable and executable product and program code having an off-chain payment hub, wherein dynamic payments and signatures can be effected, multiple smart contract payment hubs are interconnected with efficient transmission routes, and off-chain payment enactment fees can be nullified at no security cost.
US20200394651A1 – Kreder, III, et al. - Discloses a system enables cryptocurrency payment transactions between devices using off-chain asset data that is related to blockchain assets within a blockchain but without committing the payment transaction to the blockchain until a later time, wherein a device selects a settlement model to determine if a payment transaction is valid .
45. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
September 21, 2026
Prosecution Insights