DETAILED ACTION
Acknowledgements
The amendment filed 7/31/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 .
Response to Amendment/Arguments
Regarding the rejection of the claims under 35 USC 101, applicant states that claim 1 is directed to the way distributed ledger nodes validate plain-text smart contract actions using LLM-based semantic interpretation and node consensus, and therefore not directed to an abstract idea. Applicant further states that in claim 1, each node includes an LLM trained to interpret instructions and actions, and in which validation is performed through node-by-node comparison between stored portions of the plain-text smart contract and the plain-text description of the action. Applicant states that this is an improved computer-implemented validation technique for validating plaint-text smart contract actions in a distributed ledger environment. Additionally, applicant states that the claims recite an improvement to the technology of blockchain and thus integrate any alleged abstract idea into a practical application because the claims recite a node-level semantic validation layer that is built into the consensus process, including that the plain-text description of the action be checked for consistency with stored contract terms and template-derived requirements through LLM-based semantic interpretation. Applicant states that this addresses a technical problem specific to distributed ledgers and provides concrete technical benefits. Further, applicant states that the claims recite an inventive concept that amounts to significantly more than any alleged abstract idea because it provides the inventive concept of an ordered validation pipeline that includes plain-text action input, LLM-based structuring, node-by-node semantic comparison against locally stored plain-text smart-contract content, and consensus generation from those node-level determinations. Applicant states that Step 2B analysis treats the distributed-ledger nodes, LLMs, processors, and storage as conventional components, but does not address whether the ordered combination was well-understood, routine, and conventional.
Regarding the use of an LLM in the claim, examiner first notes that only actively recited step in which an LLM is used to perform any functionality is the step of “interpreting the plain text description of the action by the LLM of the first node to convert the plain text description into a structured representation.” This limitation broadly recites an LLM but does not provide any technical details regarding the LLM or the manner in which it is used. Additionally, the functionality for which the LLM is used only involves interpreting the action before performing it, which is part of the abstract idea. The claim also recites “wherein a respective portion of the consensus information is generated by each node of the at least the portion of nodes by using the respective LLM of that node to compare at least a portion of the plain text smart contract stored by that node to the plain text description of the action to determine whether the action satisfies a condition associated with the smart contract by interpreting the plain text description and ensuring semantic consistency with at least a portion of the stored plain text smart contract.” However, this limitation only describes the intended use of the consensus information by nodes other than the first node. This limitation does not gain patentable weight as the claims are directed only to the first node, and this limitation also does not require any steps to be performed as part of the claimed method, nor does it require any functionality to be performed by the claimed processor. Thus, the claims do not actively recite any steps involved in using an LLM to perform validation through node-by-node comparison between stored portions of the plain-text smart contract and the plain-text description of the action, nor do they include actively recite steps involved in a node-level semantic validation layer that is built into the consensus process, including that the plain-text description of the action be checked for consistency with stored contract terms and template-derived requirements through LLM-based semantic interpretation, or a node-by-node semantic comparison against locally stored plain-text smart-contract content, and consensus generation from those node-level determinations. Therefore, these features do not provide a practical application or significantly more than the abstract idea.
The positively recited features of the claims include the steps 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], a plain text description of an action to perform on the . . . contract,” “interpreting the plain text description of the action by . . . the first [entity] to convert the plain text description into a structured representation,” “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 steps recite an abstract idea because they 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. The additional element 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 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, only involves using a computer as a tool to automate and/or implement the abstract idea. Thus, the additional elements do not provide a practical application or significantly more than the abstract idea.
Further, regarding the argument that the Step 2B analysis treats the distributed-ledger nodes, LLMs, processors, and storage as conventional components, examiner notes that the rejection does not rely on these elements being conventional. Rather, the use of these additional elements does not provide significantly more than the abstract idea, because these elements are only used as a tool to automate the steps involved in the abstract idea.
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], a plain text description of an action to perform on the . . . contract,” “interpreting the plain text description of the action by . . . the first [entity] to convert the plain text description into a structured representation,” “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], a plain text description of an action to perform on the . . . contract,” “interpreting the plain text description of the action by . . . the first [entity] to convert the plain text description into a structured representation,” “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). Additionally, the language “wherein a respective portion of the consensus information is generated by each node of the at least the portion of nodes by using the respective LLM of that node to compare at least a portion of the plain text smart contract stored by that node to the plain text description of the action to determine whether the action satisfies a condition associated with the smart contract by interpreting the plain text description and ensuring semantic consistency with at least a portion of the stored plain text smart contract,” describes the intended use of the consensus information by nodes other than the first node. However, the claims are directed to the first node, and this limitation also does not require any steps to be performed as part of the claimed method, nor does it require any functionality to be performed by the claimed processor. Thus, this limitation recites intended use language and does not gain patentable weight. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use (MPEP §2103 I C). 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], a plain text description of an action to perform on the . . . contract,” “interpreting the plain text description of the action by . . . the first [entity] to convert the plain text description into a structured representation,” “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. Additionally, the language “wherein a respective portion of the consensus information is generated by each node of the at least the portion of nodes by using the respective LLM of that node to compare at least a portion of the plain text smart contract stored by that node to the plain text description of the action to determine whether the action satisfies a condition associated with the smart contract by interpreting the plain text description and ensuring semantic consistency with at least a portion of the stored plain text smart contract,” describes the intended use of the consensus information by nodes other than the first node. However, the claims are directed to the first node, and this limitation also does not require any steps to be performed as part of the claimed method, nor does it require any functionality to be performed by the claimed processor. Thus, this limitation recites intended use language and does not serve to differentiate the claims from the prior art. The recitation of the intended use of the claimed invention does not serve to differentiate the claim from the prior art. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use (MPEP §2103 I C). Therefore, the use of the additional elements recited in the claims 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 that 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, a plain text description of an action to perform on the smart contract, wherein the plain text description includes the identifier, interpreting the plain text description of the action by the LLM of the first node to convert the plain text description into a structured representation, 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).
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 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