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 .
Information Disclosure Statement
2. The information disclosure statement (IDS) submitted on 11/20/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC §101
3. 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.
4. Claims 1-20 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.
5. In the instant case, claims 1, 11, and 20 are directed “methods, nodes, and systems in blockchains”.
6. Claim 1 recites “managing a transaction execution”. Specifically, claim 1 recites (abstract ideas emphasized in bold) “executing, by a first node of a blockchain, a first transaction in a trusted execution environment (TEE) of the first node to obtain a first execution read-write set of the first transaction;
signing the first execution read-write set by using a private key stored in the TEE to obtain a first signature, wherein the first execution read-write set comprises a first execution read set and a first execution write set;
sending the first execution read-write set and the first signature to a second node of the blockchain;
verifying, by the second node, the first signature by using a public key corresponding to the private key;
verifying the first execution read set after the verification on the first signature succeeds; and
storing the first execution write set as an execution write set of the first transaction when the verification succeeds”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial and legal interactions), and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
7. 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 1 such as “a first node”, “a blockchain”, “a trusted execution environment (TEE)”, “a private key”, “a second node”, “a virtual model”, and “a public key” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. With respect to “sending the first execution read-write set and the first signature to a second node of the blockchain” and “storing the first execution write set as an execution write set of the first transaction when the verification succeeds” 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)).
8. 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 managing a transaction execution 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.
9. Hence, claim 1 is not patent eligible.
10. Claims 11 and 20 also recite “managing a transaction execution”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial and legal interactions), and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
11. As in the case of claim 1, 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 claims 11 and 20 such as “a non-transitory, computer-readable medium”, “a computer system”, “a first node”, “a blockchain”, “a trusted execution environment (TEE)”, “a private key”, “a second node”, “a virtual model”, “a public key”, “one or more computers”, “one or more computer memory devices”, and “tangible, non-transitory, machine-readable media” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. With respect to “sending the first execution read-write set and the first signature to a second node of the blockchain” and “storing the first execution write set as an execution write set of the first transaction when the verification succeeds” 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)).
12. 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 managing a transaction execution 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.
13. Hence, claims 11 and 20 are not patent eligible.
14. Dependent claims 2-10 and 12-19 merely expand upon the abstract ideas of the independent claims and are therefore rejected under the same rationale as claims 1 and 11 respectively.
Conclusion of 35 USC §101
15. 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.
16. 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
17. 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.
18. 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.
19. 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.
20. Claims 1-3, 10-13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US20200073962A1 to Natarajan et al. in view of US20200184093A1 to Liu et al.
21. As per claim 1:
Natarajan et al. discloses the following limitations:
A computer-implemented method for blockchain transaction execution, comprising ([0063] “FIG. 2B illustrates an example of a transactional flow 250 between nodes of the blockchain in accordance with an example embodiment…”)
executing… of the first node to obtain a first execution read-write set of the first transaction ([0065] “…The chaincode is then executed against a current state database to produce transaction results including a response value, read set, and write set. However, no updates are made to the ledger at this point…”)
signing the first execution read-write set by using … to obtain a first signature, wherein the first execution read-write set comprises a first execution read set and a first execution write set ([0063] “…The output may include the chaincode results, a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response 292 is sent back to the client 260 along with an endorsement signature, if approved…”)
sending the first execution read-write set and the first signature to a second node of the blockchain ([0067] “…the client 260 assembles endorsements into a transaction and broadcasts the transaction proposal and response within a transaction message to the ordering node 284. The transaction may contain the read/write sets, the endorsing peers’ signatures and a channel ID…”, [0068] “The blocks of the transaction are delivered from the ordering node 284 to all peer nodes 281-283 on the channel…”)
verifying, by the second node, the first signature by using a public key corresponding to the private key ([0063] “…the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293.”, [0134] “…a client (creator) identify such as a public key and certificate, a signature of the client, identities of endorsers, endorser signatures…”)
verifying the first execution read set after the verification on the first signature succeeds ([0068] “…The transactions 294 within the block are validated to ensure any endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution…”, [0132] “…each committing peer validates the transaction within the new block 750 by checking to make sure that the read set and the write set still match the current world state in the state database 734…”)
storing the first execution write set as an execution write set of the first transaction when the verification succeeds ([0068] “…each peer node 281-283 appends the block to the channel’s chain, and for each valid transaction the write sets are committed to current state database…”, [0132] “…When the committing peer validates the transaction, the transaction is written to the blockchain 732 on the distributed ledger 730, and the state database 734 is updated with the write data from the read-write set…”)
Natarajan et al. does not disclose, however, Liu et al., as shown, teaches the following limitations:
executing, by a first node of a blockchain, a first transaction in a trusted execution environment (TEE) ([0022] “…nodes in a blockchain network each may execute a received transaction in a trusted execution environment (TEE) … An identified plaintext transaction is retained in the conventional execution environment for processing …, and an identified privacy transaction is transferred to the TEE for processing…”)
[signing] … a private key stored in the TEE … ([0024] “…privacy data can be encrypted and sent to an enclave in a form of ciphertext, and a corresponding key can also be transferred into the enclave through remote attestation…”)
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 transaction scheduling method for determining, by a blockchain node, a data volume of a received privacy transaction in a trusted execution environment of Liu et al. (‘093, [0008]) with the teaching of Natarajan et al. for providing a blockchain network comprising a plurality of peer nodes programmed to generate a current state database (‘962, [0013]) for executing by the first node the first transaction in a trusted execution environment (TEE) and storing keys resident in the TEE (enclave) used for decryption (‘093, [0022], [0024]).
Claims 11 and 20 are rejected using the same rationale that was used for the rejection of claim 1.
As per claim 11 Natarajan et al. additionally discloses the following limitations:
A non-transitory, computer-readable medium storing one or more instructions executable by a computer system to perform one or more operations for blockchain transaction execution, comprising: ([0043] “…non-transitory computer readable media, devices, and/or networks, which provide the ability to create checkpoints for the state database and to perform peer operations on the blockchain…”, [claim 17] “A non-transitory computer readable medium comprising instructions, that when read by a processor, cause the processor to perform…”)
As per claim 20 Natarajan et al. additionally discloses the following limitations:
A computer-implemented system for blockchain transaction execution, comprising: ([0043] “… systems… which provide the ability to create checkpoints for the state database and to perform peer operations on the blockchain…”)
one or more computers (Fig.6A, [0119] “…The physical infrastructure 610, the module 612, and the module 614 may include one or more computers, servers, processors, memories, and/or wireless communication devices…”)
one or more computer memory devices interoperably coupled with the one or more computers and having tangible, non-transitory, machine-readable media storing one or more instructions that, when executed by the one or more computers, perform one or more operations, comprising: ([0138] “…computer system/server 802 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems…”, [0139] “Computer system/server 802 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system…”)
22. As per claim 2:
Natarajan et al. discloses the following limitations:
performing, by the second node, read-write set analysis on the first transaction to obtain a second analysis read set of the first transaction, wherein the second analysis read set of the first transaction comprises keys of multiple first variables ([0132] “… Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transaction is identical to the current world state in the state database 734…”)
reading first values of the multiple first variables when determining that the first execution read set comprises the keys of multiple first variables ([0132] “…each committing peer validates the transaction within the new block 750 by checking to make sure that the read set and the write set still match the current world state in the state database 734…”)
determining whether the first values are consistent with values of the multiple first variables in the first execution read set, wherein the verification on the first execution read set fails if the first values are inconsistent with the values of the multiple first variables in the first execution read set ([0132] “…If a transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 734, the transaction ordered into a block will still be included in that block, but it will be marked as invalid, and the state database 734 will not be updated.”)
Claim 12 is rejected using the same rationale that was used for the rejection of claim 2.
23. As per claim 3:
Natarajan et al. discloses the following limitations:
the first execution read set comprises key-value pairs of multiple second variables ([0134] “…a read set (list of key and version read by the transaction, etc.), a write set (list of key and value, etc.) …”, [0132] “…Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transaction is identical to the current world state in the state database 734…”)
verifying the first execution read set, comprises: reading second values of the multiple second variables ([0132] “…Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transaction is identical to the current world state in the state database 734…”)
determining whether the second values are consistent with values of the multiple second variables in the first execution read set, wherein the verification on the first execution read set fails if the second values are inconsistent with the values of the multiple second variables in the first execution read set ([0132] “…If a transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 734… it will be marked as invalid, and the state database 734 will not be updated.”)
Claim 13 is rejected using the same rationale that was used for the rejection of claim 3.
24. As per claim 10:
Natarajan et al. discloses the following limitations:
sending the first execution read-write set and the first signature to the second node, comprises: executing, by the first node, the first transaction in the TEE to obtain the first execution read-write set and a transaction receipt of the first transaction ([0065] “…The chaincode is then executed against a current state database to produce transaction results including a response value, read set, and write set…”)
signing the first execution read-write set and the transaction receipt by using the private key stored in the TEE to obtain the first signature ([0065] “…In 292, the set of values, along with the endorsing peer node’s 281 signature is passed back as a proposal response 292 to the SDK of the client 260 which parses the payload for the application to consume.”)
sending the first execution read-write set, the transaction receipt, and the first signature to the second node ([0067] “…The transaction may contain the read/write sets, the endorsing peers’ signatures and a channel ID…”, [0134] “…chaincode events, response status, namespace, a read set (list of key and version read by the transaction, etc.), a write set (list of key and value, etc.) …)
25. Claims 4-7 and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over US20200073962A1 to Natarajan et al. in view of US20200184093A1 to Liu et al. and US20190281065A1 to Xia et al.
26. As per claim 4:
Neither Natarajan et al. nor Liu et al. disclose, however, Xia et al., as shown, teaches the following limitations:
the first transaction is a transaction of a predetermined type, and comprising ([0064] “Smart contract calls (e.g., 405a-c) are different from other types of transactions …”, [0066] “… Smart contract call 405c is a smart contract call that does not specify a whitelist. Because smart contract call 405c can be executed by any account in the blockchain network, it cannot be executed in parallel with other transactions…”)
individually performing, by the first node, read-write set analysis on a plurality of transactions to obtain respective first analysis read-write sets of the plurality of transactions ([0073] “… the particular set of accounts associated with each of the one or more smart contract calls is determined based on the whitelist associated with the smart contract call …”, [0064] “…The whitelist thus allows smart contract calls to be grouped for parallel execution in the blockchain network along with other transactions affecting the same accounts.”)
grouping the plurality of transactions based on the plurality of transactions based on a plurality of first analysis read-write sets to obtain a plurality of transaction groups, wherein the plurality of transaction groups comprise a first transaction group and a second transaction group, the first transaction group comprises the first transaction, and the second transaction group does not comprise a transaction of the predetermined type ([0073] “…identifying groups of transactions within the plurality of transactions, wherein the transactions in each group are associated with a particular set of accounts in the blockchain network …”, [0073] “… the execution order includes a smart contract call to a smart contract that does not have a whitelist arranged after the plurality of transactions…”)
executing, by the first node, a first transaction in the TEE, comprises: executing, by the first node, transactions in the first transaction group before executing transactions in the second transaction group ([0066] “groups 455, 460, and 465 execute in parallel until reaching contract call 405 c…”)
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 transaction scheduling method for determining, by a blockchain node, a data volume of a received privacy transaction in a trusted execution environment of Liu et al. (‘093, [0008]) and methods for parallel execution of transactions in a blockchain network based on smart contract whitelists of Xia et al. (‘065, [0006]) with the teaching of Natarajan et al. for providing a blockchain network comprising a plurality of peer nodes programmed to generate a current state database (‘962, [0013]) for indicating that the first transaction is of a predetermined type, e.g., a smart contract without a whitelist is distinct transaction category subject, determining that for each transaction, the set of accounts (e.g., keys) the transaction accesses is individually, grouping the plurality of transactions based on the analysis and the predetermined-type call stands apart as its own group containing the first transaction and wherein the groups without the predetermined-type transaction execute first, and the group containing the predetermined-type transaction executes last (‘065, [0064], [0066], [0073]).
Claim 14 is rejected using the same rationale that was used for the rejection of claim 4.
27. As per claim 5:
Natarajan et al. does not disclose, however, Liu et al., as shown, teaches the following limitations:
each transaction comprises a first field used to indicate whether the transaction is a transaction of the predetermined type ([0029] “…when the type field is a first value, it indicates that the related transaction is a plaintext transaction, and when the type field is a second value, it indicates that the related transaction is a privacy transaction…”)
executing, by the first node, a first transaction in the TEE, comprises: determining, by the first node based on a first field of the first transaction, that the first transaction is a transaction of the predetermined type, providing the first transaction for the TEE, and executing the first transaction in the TEE ([0022] “A transaction submitted by a client (or another source) first enters a ‘transaction scheduling’ interface of the conventional execution environment for type identification. An identified plaintext transaction is retained in the conventional execution environment for processing …, and an identified privacy transaction is transferred to the TEE for processing …”)
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 transaction scheduling method for determining, by a blockchain node, a data volume of a received privacy transaction in a trusted execution environment of Liu et al. (‘093, [0008]) with the teaching of Natarajan et al. for providing a blockchain network comprising a plurality of peer nodes programmed to generate a current state database (‘962, [0013]) for indicating whether the transaction is of the predetermined (privacy) type and an encryption identifier added to the transaction and determining from the transaction’s type field that the transaction is of the predetermined type, and providing it to the TEE, and executing it in the TEE (‘093, [0022], [0029]).
Claim 15 is rejected using the same rationale that was used for the rejection of claim 5.
28. As per claim 6:
Neither Natarajan et al. nor Liu et al. disclose, however, Xia et al, as shown, teaches the following limitations:
individually performing, by the second node, read-write set analysis on the plurality of transactions to obtain respective second analysis read-write sets of the plurality of transactions; and comprising ([0073] “…identifying groups of transactions within the plurality of transactions …wherein the particular set of accounts associated with each of the one or more smart contract calls is determined based on the whitelist…”)
grouping, by the second node, the plurality of transactions based on a plurality of second analysis read-write sets to obtain a plurality of transaction groups, wherein the plurality of transaction groups comprise a third transaction group and a fourth transaction group, wherein the third transaction group comprises the first transaction, and wherein the fourth transaction group does not comprise a transaction of the predetermined type ([0070] “…instructing a first set of nodes to execute a first group of transactions and instructing a first set of nodes to execute a second group of transactions …”)
executing, by the second node, transactions in the fourth transaction group before executing transactions in the third transaction group ([0066] “…groups 455, 460, and 465 execute in parallel until reaching contract call 405 c. At this point, the blockchain network waits until all transactions in the groups 455, 460, and 465 have completed execution, and then proceeds with execution of the smart contract call 405 c.”)
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 transaction scheduling method for determining, by a blockchain node, a data volume of a received privacy transaction in a trusted execution environment of Liu et al. (‘093, [0008]) and methods for parallel execution of transactions in a blockchain network based on smart contract whitelists of Xia et al. (‘065, [0006]) with the teaching of Natarajan et al. for providing a blockchain network comprising a plurality of peer nodes programmed to generate a current state database (‘962, [0013]) for analyzing the transaction in the network by executing via the second node received instructions, including a group without any predetermined-type transaction and executing the fourth (e.g., non-predetermined-type) transaction groups before executing the third group containing the predetermined-type first transaction (‘065, [0066], [0070], [0073]).
Claim 16 is rejected using the same rationale that was used for the rejection of claim 6.
29. As per claim 7:
Natarajan et al. discloses the following limitations:
when executing the first transaction in the third transaction group, after determining, based on the first field of the first transaction, that the first transaction is a transaction of the predetermined type: determining, by the second node, whether the first execution read-write set of the first transaction and the first signature are received from the first node ([0068] “…The transactions 294 within the block are validated to ensure any endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution…”, [0066] “…the application determines if the specified endorsement policy has been fulfilled before submitting (i.e., did all peer nodes necessary for the transaction endorse the transaction)…”)
waiting when determining that the first execution read-write set and the first signature are not received from the first node ([0066] “…the application determines if the specified endorsement policy has been fulfilled before submitting…”)
Claim 17 is rejected using the same rationale that was used for the rejection of claim 7.
30. Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US20200073962A1 to Natarajan et al. in view of US20200184093A1 to Liu et al., US20190281065A1 to Xia et al., and US20200349568A1 to Feng
31. As per claim 8:
Neither Natarajan et al. nor Liu et al. or Xia et al. disclose, however, Feng, as shown, teaches the following limitations:
wherein the second node executes the first transaction when waiting timeout occurs or when verification on the first execution read set fails (“[0057] “…A determination is made that the user's account balance does not equal to the account balance indicated in the read-write set 430 (i.e., 60!=100). In other words, the data storage verification phase 420 for the blockchain transaction with the read-write set 430 fails, and as a result the blockchain transaction 426 fails.”, [0065] “…In some embodiments, a simple logic command can be embedded into a special instruction. The special instruction can then be used to execute a corresponding logic verification during a data storage verification phase to determine whether a corresponding data transaction can be executed successfully.”, [0020] “…The special instruction is used to validate that a current value of the piece of data supports the blockchain transaction when executing the corresponding smart contract to write the blockchain transaction to a 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 transaction scheduling method for determining, by a blockchain node, a data volume of a received privacy transaction in a trusted execution environment of Liu et al. (‘093, [0008]), methods for parallel execution of transactions in a blockchain network based on smart contract whitelists of Xia et al. (‘065, [0006]) and methods for avoiding double-spending problem in read-write set-model-based blockchain technology of Feng (‘568, abstract) with the teaching of Natarajan et al. for providing a blockchain network comprising a plurality of peer nodes programmed to generate a current state database (‘962, [0013]) for providing a logic command of the special instruction that is executed during the data storage verification phase and the transaction fails when the current value of the read variable is inconsistent with the value in the received read-write set (‘568, [0020], [0057], [0065]).
Claim 18 is rejected using the same rationale that was used for the rejection of claim 8.
32. Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US20200073962A1 to Natarajan et al. in view of US20200184093A1 to Liu et al. and US20180309567A1 Wooden.
33. As per claim 9:
Neither Natarajan et al. nor Liu et al. disclose, however, Wooden, as shown, teaches the following limitations:
a system contract is deployed in the blockchain, a contract state of the system contract stores the public key; and comprising ([0134] “…Each member listed in the blockchain’s membership metadata block is represented by the member’s public key, as well as a fragment of the BMK encrypted to that public key …”, [0134] “In some examples, the metadata includes the BPK in plaintext for integrity verification …”)
querying, by the second node, the contract state of the system contract to obtain the public key ([0110] “…the VN checks to make sure that the remote endorser is in the local membership list, and if so, the channel is considered trusted and the VN will accept blockchain updates from the remote node…”)
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 transaction scheduling method for determining, by a blockchain node, a data volume of a received privacy transaction in a trusted execution environment of Liu et al. (‘093, [0008]) and a method for storing pre-determined type of blockchain protocol code in a trusted execution environment (TEE) and TEE attestation is used to verify that the blockchain protocol code of Wooden (‘567, [0005]) with the teaching of Natarajan et al. for providing a blockchain network comprising a plurality of peer nodes programmed to generate a current state database (‘962, [0013]) for storing public keys, including the BPK used to verify TEE key signed data in membership metadata blocks and controlling counterpart keys and membership from the maintained on-chain membership data (‘567, [0110], [0134]).
Claim 19 is rejected using the same rationale that was used for the rejection of claim 9.
Conclusion
34. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20210081320A1 – Tian – Discloses methods, systems, and apparatus, including computer programs encoded on computer storage devices, for data processing and storage, wherein method includes maintaining a plurality of tiers of storage devices and one or more tiers of caches by a storage system for storing blockchain data, the plurality of tiers of storage devices including at least a higher-tier storage device and a lower-tier storage device.
US20200379977A1 – Saket et al. – Discloses a system that includes an executing client, configured to perform one or more of generate a blockchain transaction comprising one or more of an anonymous rating related to an authorizing client, and a root node value, and a blockchain network, coupled to the executing client, comprising one or more of a shared ledger.
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.
35. 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
August 21, 2026
Prosecution Insights