DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the application filed on 05/22/2024.
Claims 1-20 are currently pending and have been examined.
Claim Rejections - 35 USC § 101
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.
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.
In the instant case, claims 1, 13 and 17 are directed to a method, system, and non-transitory computer-readable recording medium. For the purposes of this analysis, representative claim 1 is addressed.
Claim 1 recites “transaction processing” which is a grouped under “Certain methods of organizing human activity — fundamental economic practices” in prong one of step 2A (MPEP 2106.04(a)). Abstract ideas are in bold below, and represents a “transaction processing”
Claim 1 recites:
A blockchain-based transaction processing method comprising:
generating at least two transaction sequences based on a smart contract invoked by each transaction in a transaction set and a contract dependency relationship, smart contracts respectively invoked by two transactions belonging to different transaction sequences being independent, and the contract dependency relationship comprising dependency information respectively corresponding to each smart contract and another smart contract;
executing the at least two transaction sequences in parallel, to obtain an operation object set of each transaction;
traversing the transaction set, and adjusting an execution order of each target transaction in the at least two transaction sequences based on the operation object set of each transaction, the target transaction being a traversed transaction and comprising a common operation object with at least one non-traversed transaction; and
re-executing each target transaction based on an adjusted execution order after traversing the transaction set.
The additional elements of claim 1, 13 and 17 such as “Smart contract” “a memory, configured to store a computer program or a computer-executable instruction; and a processor, configured to implement, when executing the computer program or the computer-executable instruction in the memory, a blockchain-based transaction processing method, performed by a transaction processing device, comprising:”, and “ A non-transitory computer-readable storage medium, having a computer program or a computer-executable instruction stored therein, wherein when the computer program or the computer-executable instruction is executed by a processor, to implement a blockchain-based transaction processing method, comprising:” 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. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to transaction processing.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount to no more than mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of transaction processing,
Hence, claims 1, 13 and 17 are not patent eligible.
Dependent claims 2-12, 14-16, and 18-20 recited additional details which only further narrow the abstract idea and do not add any additional features, alone or in combination, that would provide a practical application or provide significantly more.
The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not affect 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.
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
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3, 13-15 and 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Qiu (WO 2021/032115 A1) in view of Liu (CN 202010754103 A)
Regarding claims 1, 13 and 17
A blockchain-based transaction processing method comprising: generating at least two transaction sequences based on a smart contract invoked by each transaction in a transaction set and a contract dependency relationship, smart contracts respectively invoked by two transactions belonging to different transaction sequences being independent, and the contract dependency relationship comprising dependency information respectively corresponding to each smart contract and another smart contract; (See at least Qiu (Page 4 paragraph 2) “Step 1: Blockchain nodes receive the packaged When the transaction is executed, first extract the corresponding contract source code from the ledger database according to the contract address specified in the transaction, and load it; Step 2: For all the loaded contracts, obtain whether there are cross-contract calls in the contract through reflection If yes, take out the address of the cross-contract call, and take out the corresponding contract source code from the ledger database, load it, and recursively analyze the cross-contract call address in the contract; finally, for each transaction, get A cross-contract call link table starting with the address of the contract called by the current transaction;”
executing the at least two transaction sequences [….], to obtain an operation object set of each transaction; (See at least Qiu (Page 4 paragraph 2) Step 3: According to the call chain of all the obtained transactions corresponding to the contract, perform the call dependency analysis of all transactions,
traversing the transaction set, and adjusting an execution order of each target transaction in the at least two transaction sequences based on the operation object set of each transaction, the target transaction being a traversed transaction and comprising a common operation object with at least one non-traversed transaction; and (See at least Qiu (Page 4 paragraph 2) if the transaction contract is a calling contract , Traverse the contract call chain corresponding to this contract obtained in step 2. If the contract call chain contains contracts involved in other transactions, put these two transactions in one transaction call chain, otherwise, this transaction is separate As a transaction call chain; if the transaction contract is a deployment contract, directly treat the transaction as a transaction call chain. After analyzing the dependencies of all transactions, we finally get multiple transaction call chains that will not affect each other's execution;
re-executing each target transaction based on an adjusted execution order after traversing the transaction set. (See at least Qiu Step 4: The multiple transaction call chains obtained in step 3 will not affect each other's execution. It is executed in parallel in multiple virtual machine instances that have been turned on in advance. Each virtual machine executes a transaction link, and a single virtual machine executes serially within a single virtual machine. After all virtual machine execution links are over, the results are collected and returned to The upper layer performs other operations.
Qui does not, however Liu teaches
[where in the transactions are executed] in parallel (see “In parallel execution of transactions, collision detection between transactions is indispensable. The detection of the second conflict is similar to the conflict detection when the transaction is executed in parallel, and various conflict detection modules can be used.”).
It would have been obvious to one of ordinary skill in the art at the time of effective filing to modify Qui to include parallel processing, because the result would have improved the transaction execution efficiency. One of ordinary skill in the art would have recognized the combination as predictable.
Regarding claims 2, 14, and 18
The method according to claim 1, wherein the generating at least two transaction sequences based on a smart contract invoked by each transaction in a transaction set and a contract dependency relationship comprises: combining the smart contract invoked by each transaction in the transaction set into a transaction contract set corresponding to the transaction set; (See at least Qiu (page 2 paragraph 7) In some of the embodiments, the determination of the call dependency relationship of the transaction according to the cross-contract call link table of each transaction in the target execution transaction and the contract type of the smart contract in the target execution transaction includes: In the case that the contract type of a transaction is the calling contract, and the smart contract in the second transaction is included in the cross-contract calling link table, the second transaction is combined with the first transaction Put them into the same transaction invocation chain; in the case that the contract type of the first transaction is the deployment contract, the first transaction separately forms a transaction invocation chain.
when determining a dependent contract set from the transaction contract set based on the contract dependency relationship, for each smart contract in the dependent contract set, combining at least one transaction whose transaction sequence is not determined and that corresponds to the smart contract in the transaction set into a subset of conflict transactions, wherein the dependent contract set comprises each smart contract that has a dependency with a current smart contract, the current smart contract is a smart contract invoked by a current transaction, and the current transaction is a transaction whose transaction sequence is not determined in the transaction set; (See at least Qiu (page 7 paragraph 7) According to another aspect of the present invention, a device for parallel execution of smart contracts is provided. The device includes: a registration module for judging whether a method in a Java smart contract has an @Parallel annotation, and analyzing the @Parallel annotations The Java bytecode of the method of the Java smart contract is used to determine whether it belongs to the successfully registered contract method that can be executed in parallel; the parsing module is used to first obtain whether the called contract has a successfully registered parallel execution method when the contract is invoked. Contract method. If multiple transactions in the current block are all called contract methods that can be executed in parallel, the smart contract executor will analyze the parameters passed to the contract method in the transaction. When the parameters of the calling contract are different, it will The contract method is executed in parallel; if the parameters are the same, the dependency relationship is constructed according to the transaction sequence in the block, and the Directed Acyclic Graph is generated to determine the sequence.
combining the obtained at least one subset of conflict transactions corresponding to the dependent contract set into a first conflict transaction set of the current transaction; (See at least Qiu (page 3 paragraph 3) when the calling parameters are the same, a dependency relationship is constructed according to the order of the transaction, and a Directed Acyclic Graph is generated to determine the order of the transaction.
determining the current transaction and the first conflict transaction set as a transaction sequence; and (See at least Qiu (page 5 paragraph 1) if the parameters are the same, the dependency relationship is constructed according to the transaction sequence in the block, and the Directed Acyclic Graph is generated to determine the sequence.
obtaining the at least two transaction sequences after determining a transaction sequence to which each transaction in the transaction set belongs. (See at least Qiu (page 5 paragraph 3) The smart contract executor will analyze the parameters passed to the contract method in the transaction. When the parameters of the calling contract are different, the contract method will be executed in parallel; if the parameters are the same, According to the transaction sequence in the block, the dependency relationship is constructed, and the Directed Acyclic Graph is generated to determine the sequence.
Regarding claims 3, 15, and 19
The method according to claim 2, wherein after the combining the smart contract invoked by each transaction in the transaction set into a transaction contract set corresponding to the transaction set, and before the obtaining the at least two transaction sequences after determining a transaction sequence to which each transaction in the transaction set belongs, the method further comprises: determining the current transaction as a transaction sequence when determining that the current smart contract is independent of remaining smart contracts based on the contract dependency relationship, wherein the remaining smart contracts comprise smart contracts other than the current smart contract in the transaction contract set. (See at least Qiu (page 5 paragraph 3) To determine whether it belongs to a successfully registered contract method that can be executed in parallel; when initiating a contract call, first obtain whether the called contract has a successfully registered contract method that can be executed in parallel. If there are multiple contracts in the current block Transactions are all called contract methods that can be executed in parallel. The smart contract executor will analyze the parameters passed to the contract method in the transaction. When the parameters of the calling contract are different, the contract method will be executed in parallel; if the parameters are the same, According to the transaction sequence in the block, the dependency relationship is constructed, and the Directed Acyclic Graph is generated to determine the sequence.
Prior Art of Record Not Currently Relied Upon
The prior art does not specifically teach or render obvious:
“wherein the dependency information comprises at least one of a probability of dependence” and “determining a first operation object set corresponding to a traversed transaction based on the operation object set of each transaction, and at least one operation object set corresponding to at least one non-traversed transaction; when the first operation object set and the at least one operation object set comprise a common operation object, determining the traversed transaction as the target transaction, and combining the non-traversed transaction comprising the common operation object with the target transaction into a second conflict transaction set;”
Narayanam (US 2021/0318859 A1) Teaches: Optimization of executions of smart contract.
Shi (CN 110599166 A1) Teaches Method for obtaining transaction dependence relationship in a block chain.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY MARK JAMES whose telephone number is (571)272-5155. The examiner can normally be reached M-F 8:30am - 5:00pm EST.
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 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.
/GREGORY M JAMES/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
Prosecution Insights