DETAILED ACTION
Acknowledgements
The amendment field 3/20/2026 is acknowledged.
Claims 1, 4-5, and 21-37 are pending.
Claims 1, 4-5, and 21-37 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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after allowance or after an Office action under Ex Parte Quayle, 25 USPQ 74, 453 O.G. 213 (Comm'r Pat. 1935). Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant's submission filed on 3/20/2026 has been entered.
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, 4-5, and 21-37 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
In the instant case, claims 1, 4-5, and 21-24 are directed to a method, claims 25-31 are directed to a non-transitory computer-readable medium, and claims 32-37 are directed to a system comprising a plurality of nodes, a storage device, and at least one processor. Therefore, these claims fall within the four statutory categories of invention.
The claims recite creating a contract using a template, sharing it with other parties, performing the action according to the contract and updating the contract, validating the performance of the action after informing the other parties of the performance of the action, and sharing the updated version of the contract, which is an abstract idea. Specifically, the claims recite “receiving at a first [entity] of a plurality of [entities] . . . an instruction to create a . . . contract, wherein the instruction is entered . . . as a first prompt, . . . ,” “creating, by the first [entity], the . . . contract as a plain text contract based on the instruction, wherein the creating comprises: identifying a template of the . . . contract based on an identifier in the instruction, retrieving the template upon identifying the template, verifying information in the instruction adheres to requirements of the template, and populating fields of the template based on the instructions once verified,” “transmitting, by the first [entity] and to the plurality of [entities], the . . . contract to be stored on each of the plurality of [entities], wherein the plurality of [entities] are to track and manage the . . . contract,” “receiving, by the first [entity], an action to perform on the . . . contract,” “interpreting the action by . . . the first [entity],” “performing the action by the first [entity] to obtain an updated . . . contract,” “transmitting, by the first [entity], a notification of performing the action to the plurality of [entities],” “validating the action based on consensus information of at least a portion of [entities] of the plurality of [entities],” and “transmitting the updated . . . contract to each of the plurality of [entities] for storage on each of the plurality of [entities] upon validating the action,” which is grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (MPEP 2106.04 & 2106.04(a)) because the claims describe a process of creating a contract an updating it based on an action performed on the contract, involving steps of receiving an instruction to create a contract, creating the contract by retrieving and populating a template, sharing the contract with other parties, performing an action and updating the smart contract based on the action, validating the action, and sharing the updated version of the contract, which is a commercial or legal interaction. Accordingly, the claims recite an abstract idea (See MPEP 2106.04(a)).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106.04(d)), the additional elements of the claims such as a first node of a plurality of nodes associated with a distributed ledger, a first user interface of a first user device, a smart contract, a large language model (LLM) implemented on each node and trained to interpret the instruction and actions related to the smart contract, a non-transitory computer readable medium of a node of a plurality of nodes associated with a distributed ledger, storing instructions thereon executed by at least one processor of the node, and a system comprising a plurality of nodes, a storage device, and at least one processor, merely use a computer as a tool to perform an abstract idea. Specifically, these additional elements perform the steps or functions of “receiving at a first [entity] of a plurality of [entities] . . . an instruction to create a . . . contract, wherein the instruction is entered . . . as a first prompt, . . . ,” “creating, by the first [entity], the . . . contract as a plain text contract based on the instruction, wherein the creating comprises: identifying a template of the . . . contract based on an identifier in the instruction, retrieving the template upon identifying the template, verifying information in the instruction adheres to requirements of the template, and populating fields of the template based on the instructions once verified,” “transmitting, by the first [entity] and to the plurality of [entities], the . . . contract to be stored on each of the plurality of [entities], wherein the plurality of [entities] are to track and manage the . . . contract,” “receiving, by the first [entity], an action to perform on the . . . contract,” “interpreting the action by . . . the first [entity],” “performing the action by the first [entity] to obtain an updated . . . contract,” “transmitting, by the first [entity], a notification of performing the action to the plurality of [entities],” “validating the action based on consensus information of at least a portion of [entities] of the plurality of [entities],” and “transmitting the updated . . . contract to each of the plurality of [entities] for storage on each of the plurality of [entities] upon validating the action.” Viewed as a whole, the use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106.05), the additional elements of using a first node of a plurality of nodes associated with a distributed ledger, a first user interface of a first user device, a smart contract, a large language model (LLM) implemented on each node and trained to interpret the instruction and actions related to the smart contract, a non-transitory computer readable medium of a node of a plurality of nodes associated with a distributed ledger, storing instructions thereon executed by at least one processor of the node, and a system comprising a plurality of nodes, a storage device, and at least one processor to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of creating a contract using a template, sharing it with other parties, performing the action according to the contract and updating the contract, validating the performance of the action after informing the other parties of the performance of the action, and sharing the updated version of the contract. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions of “receiving at a first [entity] of a plurality of [entities] . . . an instruction to create a . . . contract, wherein the instruction is entered . . . as a first prompt, . . . ,” “creating, by the first [entity], the . . . contract as a plain text contract based on the instruction, wherein the creating comprises: identifying a template of the . . . contract based on an identifier in the instruction, retrieving the template upon identifying the template, verifying information in the instruction adheres to requirements of the template, and populating fields of the template based on the instructions once verified,” “transmitting, by the first [entity] and to the plurality of [entities], the . . . contract to be stored on each of the plurality of [entities], wherein the plurality of [entities] are to track and manage the . . . contract,” “receiving, by the first [entity], an action to perform on the . . . contract,” “interpreting the action by . . . the first [entity],” “performing the action by the first [entity] to obtain an updated . . . contract,” “transmitting, by the first [entity], a notification of performing the action to the plurality of [entities],” “validating the action based on consensus information of at least a portion of [entities] of the plurality of [entities],” and “transmitting the updated . . . contract to each of the plurality of [entities] for storage on each of the plurality of [entities] upon validating the action.” These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of creating a contract using a template, sharing it with other parties, performing the action according to the contract and updating the contract, validating the performance of the action after informing the other parties of the performance of the action, and sharing the updated version of the contract. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05 (f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 4-5, 21-24, 26-31, and 33-37 further describe the abstract idea of creating a contract using a template, sharing it with other parties, performing the action according to the contract and updating the contract, validating the performance of the action after informing the other parties of the performance of the action, and sharing the updated version of the contract. Specifically, claims 4, 28, and 35 further describe signing the contract, which is part of the abstract idea as it is a manner of indicating agreement or verification. Claims 5, 29, and 36 describe the type of consensus protocol used. This recites an additional element, but does not provide a practical application or significantly more than the abstract idea because it only involves using a computer as a tool to automate and/or implement the abstract idea. Claims 21, 26, and 33 describe a characteristic of the identifier, but do not require any steps or functions to be performed. Claims 22, 27, and 34 further describe storing the contract, which is part of the abstract idea as it only involves storing information. Claims 23 and 30 further describe the technology that the distributed ledger is implemented in, but do not require any steps or functions to be performed. Claims 24, 31, and 36 further describe receiving an indication upon validation of the action, which further describes the abstract idea as it only involves receiving information regarding validation of the action. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Statement Regarding Prior Art
The closest prior art of Choudhari, et al. (US 2021/0286936) (“Choudhari”) discloses sending, to a plurality of nodes associated with a distributed ledger, a plain text smart contract, wherein each node of the plurality of nodes is associated with a respective language model trained to interpret plain text (Choudhari ¶¶ 10-11; 29-39, 46, 48-54), sending a transaction for the smart contract to the plurality of nodes (Choudhari ¶¶ 32, 41, 46, 55), and validating, based on consensus information received from at least a portion of nodes of the plurality of nodes, the transaction (Choudhari ¶¶ 32, 39-42 ,46, 55). Additionally, Morrisett, et al. (US 2024/0370710) (“Morrisett”) discloses the use of a large language model (Morrisett ¶¶ 4, 24, 68), as well as a transaction that is sent to the nodes in the form of a plain text description (Morrisett ¶¶ 73, 85-86). Morrisett also discloses that a respective portion of the consensus information is generated by each node of the at least the portion of nodes based on at least a portion of the plain text smart contract stored by the node compared to the plain text description of the transaction by the respective large language model (Morrisett ¶¶ 19, 24-26, 40, 35, 55, 60, 73-74, 86-87, 89). Morrisett further discloses that the plain text smart contract is verified by each node of the plurality of nodes using the respective large language model for the node to compare the plain text smart contract to a plain text template stored by the node (Morrisett ¶¶ 19, 24-26, 40, 35, 55, 60, 73-74, 86-87, 89), and that the plain text description of the transaction is verified by the respective large language model for each node of the plurality of nodes (Morrisett ¶¶ 19, 24-26, 40, 35, 55, 60, 73-74, 86-87, 89). Finally, Williams, et al. (US 11,468,431) (“Williams”) discloses that the consensus information is based on a consensus protocol between at least the portion of nodes of the plurality of nodes comprising at least one of a Byzantine Fault Tolerance (BFT), Proof of Work (PoW), Proof of Stake (PoS), or Proof of Authority (PoA) (Williams 15:63-16:8; 17:4-10, 38-45; Claim 1).
However, the prior art does not disclose, neither singly nor in combination, the specific series of steps required by the present claims, which first require creating a smart contract using a template based on a prompt received from a first device by receiving, at a first node of a plurality of nodes associated with a distributed ledger and via a first user interface of a first user device, an instruction to create a smart contract, wherein the instruction is entered into the first user interface as a first prompt, creating, by the first node, the smart contract as a plain text contract based on the instruction, wherein the creating comprises: identifying a template of the smart contract based on an identifier in the instruction, retrieving the template upon identifying the template, verifying information in the instruction adheres to requirements of the template, and populating fields of the template based on the instructions once verified, and the claims next require that, after the smart contract is stored on the plurality of nodes, receiving, by the first node, an action to perform on the smart contract, interpreting the action by the LLM of the first node, performing the action by the first node to obtain an updated smart contract, and validating the action based on consensus information of at least a portion of the nodes of the plurality of nodes.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Choudhari, et al. (US 2021/0286936) (“Choudhari”) discloses
sending, to a plurality of nodes associated with a distributed ledger, a plain text smart contract, wherein each node of the plurality of nodes is associated with a respective language model trained to interpret plain text (Choudhari ¶¶ 10-11; 29-39, 46, 48-54);
sending a transaction for the smart contract to the plurality of nodes (Choudhari ¶¶ 32, 41, 46, 55);
validating, based on consensus information received from at least a portion of nodes of the plurality of nodes, the transaction (Choudhari ¶¶ 32, 39-42 ,46, 55).
Morrisett, et al. (US 2024/0370710) (“Morrisett”) discloses the use of a large language model (Morrisett ¶¶ 4, 24, 68), as well as a transaction that is sent to the nodes in the form of a plain text description (Morrisett ¶¶ 73, 85-86). Morrisett also discloses that a respective portion of the consensus information is generated by each node of the at least the portion of nodes based on at least a portion of the plain text smart contract stored by the node compared to the plain text description of the transaction by the respective large language model (Morrisett ¶¶ 19, 24-26, 40, 35, 55, 60, 73-74, 86-87, 89).
Williams, et al. (“Williams”) discloses that the consensus information is based on a consensus protocol between at least the portion of nodes of the plurality of nodes comprising at least one of a Byzantine Fault Tolerance (BFT), Proof of Work (PoW), Proof of Stake (PoS), or Proof of Authority (PoA) (Williams 15:63-16:8; 17:4-10, 38-45; Claim 1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohammad A. Nilforoush whose telephone number is (571)270-5298. The examiner can normally be reached Monday-Friday 12pm-7pm.
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, John W. Hayes can be reached at 571-272-6708. 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.
/Mohammad A. Nilforoush/Primary Examiner, Art Unit 3697
Prosecution Insights