DETAILED ACTION
This is a final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 20 in application 18/583,346.
Claims 1, 3-6, 9-11, 13-16, 19, and 20 have been amended.
Claims 1-20 are pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
35 USC 101
Applicant’s arguments filed on 8/29/2025 with respect to the 35 USC 101 Rejection of claims 1-20 have been fully considered and are persuasive. The 35 USC 101 Rejection of claims 1-20 has been withdrawn.
103 Rejection
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Garg (US20220171763A1) .
Regarding Claims 1 and 11. Garg teaches:
A method comprising:
Garg - Embodiments of the present disclosure include a method, system, and computer program product (¶ 0003).
one or more processors; and
Garg - one or more processor (¶ 0093).
a memory storing processor-executable instructions that, when executed by the one or more processors, cause the apparatus to:
Garg - a memory subsystem 504, a terminal interface 512, a storage interface 516, an I/O (Input/Output) device interface 514, and a network interface 518, all of which may be communicatively coupled, directly or indirectly, for inter-component communication via a memory bus 503, an I/O bus 508, and an I/O bus interface unit 510 (¶ 0093).
determining, by a computing device, a plurality of digital assets in a blockchain network;
Note – determining multiple assets corresponds to identifying multiple asset key/value entries in the blockchain network.
Garg - A transaction may result in a set of asset key-value pairs being committed to the ledger (¶ 0027). Chaincode invocations execute transactions against the current state data of the ledger. To make these chaincode interactions efficient, the latest values of the keys may be stored in a state databas (¶ 0029).
generating, based on each digital asset of the plurality of digital assets, a plurality of smart contracts,
Garg - The result 128 may include a plurality of linked shared documents (e.g., with each linked shared document recording the issuance of a smart contract in regard to the group transaction information 126, etc.) (¶ 0038).
wherein each smart contract of the plurality of smart contracts is associated with one or more peer nodes of a plurality of peer nodes in the blockchain network;
Garg - An endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed by the peers (¶ 0024).
causing, based on the generation of the plurality of smart contracts, one or more records to be generated and stored on one or more computing nodes of a decentralized computing system of the blockchain network,
Garg - a decentralized database (such as a blockchain) that is a distributed storage system, which includes multiple nodes that communicate with each other. The decentralized database includes an append-only immutable data structure resembling a distributed ledger capable of maintaining records between mutually untrusted parties. Each peer maintains a copy of the database records and no single peer can modify the database records (¶ 0021).
wherein the one or more records comprise data indicative of a plurality of blockchain indexes associated with the plurality of smart contracts,
Garg - The state database may be simply an indexed view into the chain's transaction log (¶ 0029).
wherein the one or more records further comprise data indicative of each smart contract, of the plurality of smart contracts, associated with each digital asset of the plurality of digital assets:
Garg - A smart contract may be created via a high-level application and programming language, and then written to a block in the blockchain. The smart contract may include executable code which is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied (¶ 0039).
causing, based on the one or more peer nodes satisfying one or more smart contract requirements of the plurality of smart contracts, the plurality of blockchain indexes to update: and
Garg - If enough peers to satisfy the endorsement policy produce identical execution results, the transaction is considered endorsed (¶ 0024). check the endorsement policy to ensure that the correct allotment of the specified peers have signed (¶ 0042). for each valid transaction the write sets are committed to current state database (¶ 0047).
causing, based on at least one blockchain index of the plurality of blockchain indexes satisfying a peer node threshold, at least one digital asset of the plurality of digital assets to be stored in a database.
Garg - When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed by the peers, which generate speculative transaction results. If enough peers to satisfy the endorsement policy (¶ 0024). “Then” for each valid transaction the write sets are committed to current state database (¶ 0047).
Regarding Claims 2 and 12. Garg further teaches:
The method of claim 1 and apparatus of claim 11, wherein each digital asset of the plurality of digital assets comprises a research study project.
Garg - A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain (¶ 0027).
Regarding Claims 3 and 13. Garg further teaches:
The method of claim 1 and apparatus of claim 11, wherein each smart contract is stored in a blockchain ledger of the blockchain network according to a transaction number and a block number identifying a location of the smart contract in the blockchain ledger.
Garg - After endorsement, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks (¶ 0024).
Regarding Claims 4 and 14. Garg further teaches:
The method of claim 1 and apparatus of claim 11, wherein each smart contract comprising data indicative of one or more of a review process, a collaboration process, a data analytics review process, or a linguistics review process associated with a digital asset of the plurality of digital assets.
Garg - The smart contracts can themselves be used to identify rules associated with authorization and access requirements and usage of the ledger. For example, the group transaction information 126 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 116. The result 128 may include a plurality of linked shared documents (e.g., with each linked shared document recording the issuance of a smart contract in regard to the group transaction information 126, etc.). The physical infrastructure 114 may be utilized to retrieve any of the data or information described herein (¶ 0038).
Regarding Claims 5 and 15. Garg further teaches:
The method of claim 1 and apparatus of claim 11, further comprising determining, based on a review process of each transaction smart contract, a peer node threshold associated with each smart contract.
Garg - An endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed by the peers, which generate speculative transaction results. If enough peers to satisfy the endorsement policy produce identical execution results, the transaction is considered endorsed. After endorsement, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks. Traditionally used consensus protocols include first-in first-out (FIFO), and leader and follower protocols (e.g., Crash fault tolerance protocols) (¶ 0024).
Regarding Claims 6 and 16. Garg further teaches:
The method of claim 5 and apparatus of claim 15, wherein each review process comprises one or more of a required number of reviews associated with the one or more peer nodes, one or more required reviews associated with the one or more peer nodes associated with one or more characteristics, or one or more levels of review of a digital asset.
Garg - An endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed by the peers, which generate speculative transaction results. If enough peers to satisfy the endorsement policy produce identical execution results, the transaction is considered endorsed (¶ 0024).
Regarding Claims 7 and 17. Garg further teaches:
The method of claim 6 and apparatus of claim 16, wherein the one or more characteristics comprise one or more of an academic level of a peer node or a background of a peer node.
Garg - . User portal 446 provides access to the cloud computing environment for consumers and system administrators. Service level management 448 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment 450 provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA (¶ 0029).
Regarding Claims 8 and 18. Garg further teaches:
The method of claim 6 and apparatus of claim 16, wherein the one or more levels of review are associated with one or more parameters, wherein the one or more parameters comprise one or more of a required number of reviews by one or more peer nodes of one or more backgrounds or a review by a required peer node.
Garg - An endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed by the peers, which generate speculative transaction results. If enough peers to satisfy the endorsement policy produce identical execution results, the transaction is considered endorsed. After endorsement, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks. Traditionally used consensus protocols include first-in first-out (FIFO), and leader and follower protocols (e.g., Crash fault tolerance protocols) (¶ 0024).
Regarding Claims 9 and 19. Garg further teaches:
The method of claim 4 and apparatus of claim 14, wherein each blockchain index of the plurality of blockchain indexes is updated based on one or more reviews by the one or more peer nodes associated with each smart contract.
Garg - The state database may be simply an indexed view into the chain's transaction log, it can therefore be regenerated from the chain at any time. The state database may automatically be recovered (or generated if needed) upon peer node startup, and before transactions are accepted (¶ 0029).
Regarding Claims 10 and 20. Garg further teaches:
The method of claim 1 and apparatus of claim 11, wherein the database is associated with one or more digital libraries.
Garg - The decentralized database includes an append-only immutable data structure resembling a distributed ledger capable of maintaining records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records and no single peer can modify the database records without a consensus being reached among the distributed peers. For example, the peers may execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain over the blocks. This process forms the ledger by ordering the storage transactions, as is necessary, for consistency (¶ 0021).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Guar et al. (US20230092436A1) - An example operation may include one or more of receiving a request for executing a trade transaction with a digital token, determining to execute an additional verification on the digital token based on one or more of a newness of the digital token and a lack of data on the digital token, querying a blockchain ledger associated with the digital token for one or more additional data attributes of the digital token, and determining whether or not to execute the trade transaction with the digital token based on the one or more additional data attributes of the digital token queried from the blockchain ledger.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C STEVENSON whose telephone number is (571)270-7280. The examiner can normally be reached on Monday to Friday to 8am-5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee, can be reached at telephone number 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/C.C.S./Examiner, Art Unit 3698 /PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698