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
Claims 1, 12, and 20 have been amended by Applicant. Claims 8 and 18 are cancelled and no new claims have been added. Claims 1-7, 9-17, and 19-20 are currently pending.
Priority
Applicant has claimed the benefit of Provisional Application 63/463,472 filed 5/02/2023. However, there is no support in the Provisional Application for the limitation “based on a plurality of ML models producing divergent actions from the natural language input, initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state”, as recited claims 1, 12, and 20 (as amended). Therefore, the effective filing date for said limitation has been determined to be 5/02/2024.
Response to Arguments
The rejection of claims 1, 2, 3, 5, 6, 7, 10, 11, 12, 13, 15, 16, 17, 19, and 20 under 35 U.S.C. 103 has been withdrawn in view of Applicant’s amendments to independent claims 1, 12, and 20. However, upon further consideration and in view of said amendments, a new ground of rejection has been made herein under 35 U.S.C. 103.
The rejection of claims 4 and 14 under 35 U.S.C. 103 has been withdrawn in view of Applicant’s amendments to independent claims 1 and 12. However, upon further consideration and in view of said amendments, a new ground of rejection has been made herein under 35 U.S.C. 103.
The rejection of claim 9 under 35 U.S.C. 103 has been withdrawn in view of Applicant’s amendments to independent claim 1. However, upon further consideration and in view of said amendments, a new ground of rejection has been made herein under 35 U.S.C. 103.
Applicant argues (in pg. 9 of Applicant’s remarks) that Padmanabhan does not teach the amended limitation …, wherein a version of the ML model to be used is specified in the transaction. In support, Applicant argues that Padmanabhan does not teach a transaction-level selection of an ML model version.
Examiner respectfully disagrees with Applicant’s argument above as it is directly contradicted by the Padmanabhan reference itself. As set forth in the instant office action Padmanabhan has been shown to teach the limitation …, wherein a version of the ML model to be used is specified in the transaction. To this effect, Padmanabhan, Paragraph [0055] teaches receiving a request to register the AI model with an audit record keeping service; receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.);
Padmanabhan [0463] further teaches the transactions include data which describes a collection of data descriptors from the following exemplary list: what decision was made by the AI trained model, what version of the AI model made the decision, what decision was made, what collection of training data was utilized to train the AI model, any confidence score or predictive score output by the AI model, what Einstein cloud platform features or GUIs were utilized, and AI intermediate node decision points triggered to lead to the output decision by the Einstein cloud platform.
Padmanabhan [0490] further teaches it is therefore important that the precise details of that AI model be recorded and tracked for the purposes of having an audit trail, in the event that a customer, the business, administrator, etc., seeks to understand what AI model was utilized to make a decision (e.g., such as a credit acceptance or denial decision), as well as precisely what version of that AI model was utilized.
Padmanabhan [0621] further teaches according to such an embodiment, the system 1301 is further operable to execute instructions for receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.
In view of the above, it has been understood that the combination in view of Padmanabhan teaches the argued limitation.
Applicant’s remaining arguments with respect to claim(s) 1, 12, and 20 (as amended) 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 § 103
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.
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 non-obviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 3, 5, 6, 7, 10, 11, 12, 13, 15, 16, 17, 19, and 20 (as amended) are rejected under 35 U.S.C. 103 as being unpatentable over Shillingford et al. (US 20220292268 A1, filed Mar. 11, 2022 and published Sep. 15, 2022) in view of Kumar Kumaresan et al.(US 20210004794 A1, hereinafter “Kumar”, filed Jul. 2, 2019 and published Jan. 7, 2021), Padmanabhan et al. (US 20200252205 A1, filed Jan. 29, 2020 and published Aug. 6, 2020), Yang et al., “Confidence Calibration and Rationalization for LLMs via Multi-Agent Deliberation” (16 Apr., 2024), and Jumnongsaksub, “Reducing smart contract runtime errors on Etherreum blockchain”, (2020),
Regarding claim 1, Shillingford teaches a computer-implemented method for implementing transactions in a blockchain platform (Note: for implementing transactions in a blockchain platform is being understood as intended use language not limiting the structure of the claim invention, See MPEP 2111.02(II)), the method comprising:
receiving a natural language input specifying a transaction to be performed on a blockchain (Shillingford, Paragraph [0029] teaches a smart contract generation system 200 may receive, at 210, a written document or audio exchange containing contract terms. The system may extract, at 212, terms, such as contract terms, from the received document or audio exchange using a natural language processing model (e.g., a machine learning-based model, such as a fine-tuned adaptation of GPT-3 or BERT model). The system may identify, at 214, chaincodes within a library of chaincodes that correspond to each extracted contract term… The system may then assemble, at 216, the individual chaincodes to generate a smart contract to effectuate the original contract terms using a smart contract in a blockchain.);
…, determining actions corresponding to the natural language input using the (ML) model (Shillingford, Paragraph [0031] a system receives, at 220, a written document (e.g., structured or unstructured) and/or an audio file that contains contract terms. The written document or audio file may be, for example, a written contract, a high-level term sheet, email correspondence, voice records of a deal between two or more parties, a single party document such as a will or trust, and/or another document that specifies actions to be taken with respect to one or more parties in response to triggering events or detectable “states.” The system may, according to any of the embodiments described herein, extract, at 222, contract terms using various natural language processing (NLP) techniques.; The system may extract, at 212, terms, such as contract terms, from the received document or audio exchange using a natural language processing model (e.g., a machine learning-based model, such as a fine-tuned adaptation of GPT-3 or BERT model [i.e., transformer based models – GPT-3 teaches large language model).); and
based on the confirmed actions, executing the transaction on the blockchain based on the actions (Shillingford, Paragraph [0033] teaches the smart contract generation system assembles the chaincodes of the discrete contract terms [i.e., contract terms teaches based on actions] together with the smart contract units associated with the compound contract terms to generate, at 236, a smart contract. The auto-executing smart contract can be stored to a blockchain platform for the irrevocable and immutable execution of the original terms of the received contract.; Shillingford, Paragraph [0019] teaches the contracting parties and/or their attorneys may review the functionality of the chaincodes generated to confirm that the chaincodes accurately correlate to the natural language contract terms.; Shillingford [0034] further teaches The chaincodes and smart contract units may be assembled, at 236, to generate a complete smart contract. In some embodiments, the system may then test, at 238, the smart contract against the original contract (e.g., the system's understanding of the original contract as processed by a natural language processing algorithm) to confirm that the functionality is equivalent.).
However, Shillingford does not distinctly disclose:
based on the natural language input, determining an intent and contextual information associated with the transaction using a machine learning (ML) model, wherein a version of the ML model to be used is specified in the transaction;
based on the intent and the contextual information [determining actions corresponding to the natural language input using the ML model]
generating, using the version of the ML model, a natural language output describing the determined actions for user confirmation;
based on a plurality of ML models producing divergent actions from the natural language input, initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless, Kumar teaches:
based on the natural language input, determining an intent and contextual information associated with the transaction using a machine learning (ML) model, … (Kumar, Paragraph [0040] teaches the smart contract creating device 108 processes a plurality of contract documents created in natural language [i.e., teaches natural language input] and associated with the plurality of assets. Thereafter, in response to the processing, Natural Language Processing (NLP) is performed based on an Artificial Intelligence (Al) model [i.e., teaches machine learning model] to generate a smart contract template for the current asset.; Paragraph [0007] teaches a method for automatically generating personalized smart contracts is disclosed [i.e., smart contracts teaches transactions].; Kumar, Paragraph [0021] teaches the system 100 generates context aware smart contracts, each of which is unique to a particular transaction.; Kumar, Paragraph [0022] further teaches the requirements [i.e., actions] and context for a particular transaction may be provided by one of stakeholders 106-1 to 106-n [i.e., teaches contextual information and natural language input], collectively referred to as a plurality of stakeholders 106; Kumar, Paragraph [0045] teaches at step 314, the smart contract creating device 108 may receive a plurality of details from the stakeholder [i.e., natural language input] of the current in addition to the plurality of asset attributes from the current asset. At step 316, the smart contract creating device 108 extracts a context and a plurality of features from the plurality of details received from the stakeholder and the plurality of asset attributes received from the current asset. At step 318, the smart contract creating device 108 populates the current smart contract template based on the context and the plurality of features to generate a current smart contract for the current asset.; Kumar, Paragraph [0068] further teaches each of the smart contract templates 602 and 604 include input parameters and business rules [i.e., teaches intent]);
based on the intent and the contextual information determining actions corresponding to the natural language input using the ML model (Kumar, Paragraph [0007] teaches a method for automatically generating personalized smart contracts is disclosed.; Kumar, Paragraph [0021] teaches the system 100 generates context aware smart contracts, each of which is unique to a particular transaction.; Kumar, Paragraph [0022] further teaches the requirements [i.e., teaches determining actions, as claimed] and context for a particular transaction may be provided by one of stakeholders 106-1 to 106-n [i.e. natural language input], collectively referred to as a plurality of stakeholders 106…The context, for example, may include, but are not limited to location of usage, person using it, or a type associated with an asset.; Kumar, Paragraph [0045] teaches at step 314, the smart contract creating device 108 may receive a plurality of details from the stakeholder [i.e., natural language input] of the current in addition to the plurality of asset attributes from the current asset. At step 316, the smart contract creating device 108 extracts a context and a plurality of features from the plurality of details received from the stakeholder and the plurality of asset attributes received from the current asset. At step 318, the smart contract creating device 108 populates the current smart contract template based on the context and the plurality of features to generate a current smart contract for the current asset. As a result, after generation of the smart contract template, the smart contract creating device 108 fills in the recommended values for each of the parameters that is very specific to each transaction, context, asset and stakeholder.; Kumar, Paragraph [0068] further teaches in FIG. 6, a smart contract template 602 associated with the asset category of backhoe loader and a smart contract template 604 associated with the asset category of broad paper machines is depicted. Each of the smart contract templates 602 and 604 include input parameters and business rules [i.e., teaching intent].; Kumar, Paragraph [0040] teaches the smart contract creating device 108 processes a plurality of contract documents created in natural language and associated with the plurality of assets. Thereafter, in response to the processing, Natural Language Processing (NLP) is performed based on an Artificial Intelligence (Al) model [i.e., teaching using ML model] to generate a smart contract template for the current asset.);
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford, with the generation of context aware smart contracts, as taught by Kumar, in order to provide a more personalized, dynamic and deployable smart contract that is unique for an asset, a user, and a transaction. (Kumar, Paragraph [0050])
However the combination does not distinctly disclose:
…, wherein a version of the ML model to be used is specified in the transaction;
generating, using the version of the ML model, a natural language output describing the determined actions for user confirmation;
based on a plurality of ML models producing divergent actions from the natural language input, initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless Padmanabhan teaches:
…, wherein a version of the ML model to be used is specified in the transaction (Padmanabhan, Paragraph [0055] teaches receiving a request to register the AI model with an audit record keeping service; receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.; Padmanabhan [0463] further teaches the transactions include data which describes a collection of data descriptors from the following exemplary list: what decision was made by the AI trained model, what version of the AI model made the decision, what decision was made, what collection of training data was utilized to train the AI model, any confidence score or predictive score output by the AI model, what Einstein cloud platform features or GUIs were utilized, and AI intermediate node decision points triggered to lead to the output decision by the Einstein cloud platform.
Padmanabhan [0490] further teaches it is therefore important that the precise details of that AI model be recorded and tracked for the purposes of having an audit trail, in the event that a customer, the business, administrator, etc., seeks to understand what AI model was utilized to make a decision (e.g., such as a credit acceptance or denial decision), as well as precisely what version of that AI model was utilized.
Padmanabhan [0621] further teaches according to such an embodiment, the system 1301 is further operable to execute instructions for receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.);
generating, using the version of the ML model, a natural language output describing the determined actions for user confirmation (Padmanabhan, Paragraph [0055] teaches receiving a request to register the AI model with an audit record keeping service; receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.; Padmanabhan, Paragraph [0158] further teaches a Simplified Payment Verification (SPV) proof 181 associated with the parent blockchain 188 asset is generated as the output and communicated to the sidechain 189. The SPV proof may include a threshold level of work, and the generating may take place over a predetermined period of time, which may also be referred to as a confirmation period 152. The confirmation period of a transfer between chains may be a duration for which a coin, token, or other exchanged value is locked on the parent blockchain 188 before may successfully be transferred to the sidechain 189 pursuant to the send SPV-locked output operation 127.; Padmanabhan, Paragraph [0159] further teaches consider for instance an exemplary confirmation period which may be on the order of 1-2 days. The confirmation period may be implemented, in such an example, as a per-sidechain security parameter, which trades off cross-chain transfer speeds in exchange for greater security. Other confirmation periods which are much shorter may be utilized where sufficiently difficult proof of work conditions are effectuated so as to ensure adequate security so as to protect the integrity of both blockchains and negate the potential for fraudulent transactions.; Padmanabhan, Paragraph [0160] further teaches after creating the output on the parent blockchain 188, the user waits out the confirmation period, meanwhile, intra-chain transfers 153 continue to occur. Subsequent to waiting out the confirmation period 122, a transaction is then created on the sidechain 189 referencing the output from the parent blockchain 188.);
However, the combination does not distinctly disclose based on a plurality of ML models producing divergent actions from the natural language input, initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless, Yang teaches based on a plurality of ML models producing divergent actions from the natural language input,… (Yang, Figure 2, teaches plurality of LLM agents producing divergent actions with varying confidence values from the natural language prompt; Yang, Section 3.1, further teaches we obtain a set of unique and diverse answers (“stances”) using a GPT-3.5 judge. This constitutes the output of the first stage: semantically unique stances each with a corresponding frequency and aggregated mean confidence; Yang, Section 3.2 further teaches the diverse stances from Stage 1 are assigned to the general agents as deliberators).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford in view of Kumar and Padmanabhan, to further include the plurality of LLM agents stance generation, as taught by Yang, in order to demonstrate the effectiveness of collaborative calibration on generative QA tasks across various domains showing its potential in harnessing the rationalization of collectively calibrated confidence assessments and improving the reliability of model predictions. (Yang, Abstract and pg. 2, par. 2)
However, the combination does not distinctly disclose:
…initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless, Jumnongsaksub teaches …initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state (Jumnongsaksub, pg. 3, teaches when the EVM detects a fatal error, it halts the current execution, reverts the global state, and marks the transaction as failed).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford in view of Kumar, Padmanabhan, and Yang, to further include the algorithm to detect smart contract methods with bad transaction behavior, as taught by Jumnongsaksub, in order to reduce the number of failed transactions on the Ethereum blockchain by helping users to avoid sending transactions that will result in failure. This will improve the transaction processing performance of the overall network since transactions that are likely to fail are prevented and most of the transactions selected by miners for validation are successful transactions. Furthermore, we can reduce the overall storage of the blockchain by storing fewer failed transactions. (Jumnongsaksub, pg. 3, par. 2 and pg. 4, par. 1)
Regarding claim 2, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 1, and the combination further teaches wherein the ML model is embedded within validator nodes of a blockchain network (Kumar, Paragraph [0046] teaches the smart contract creating device 108 validates the current smart contract in order to verify if the created smart contract template suits the current asset as well as the stakeholder (asset owner); Kumar, Paragraph [0032] teaches in absence of smart contract templates based upon asset domain ontology, the NLP registrar 222 is configured to create smart contract templates based on machine learning techniques from generalized English agreement copies associated with similar assets.; Kumar, Fig. 2 teaches smart contract template validator 210; Kumar, Paragraph [0030] teaches the smart contract template validator 210 is configured to validate the smart contract after generation. Once the personalized smart contract template is generated, the smart contract templates are validated to examine if the generated templates suit the asset and/or asset owner.; Paragraph [0040] teaches Natural Language Processing (NLP) is performed based on an Artificial Intelligence (Al) model to generate a smart contract template for the current asset. This is further explained in detail in conjunction with FIGS. 5A and 5B. [i.e., AI model teaches ML model, as claimed]; Kumar, Paragraph [0053] teaches referring now to FIGS. 5A and 5B, a flowchart of a method for automatically generating personalized smart contracts in different scenarios is illustrated, in accordance with an embodiment. At step 502, the smart contract creating device 108 identifies a plurality of asset attributes associated with a current asset within a blockchain network.; Kumar, Figs 5A and 5B.; Kumar, Paragraph [0028] teaches [from Fig. 2] the edge device 202 may include the processor 110 and the memory 112 disclosed in the FIG. 1. The memory 112 may include a smart contract trainer 206, a smart contract template requester 208, a smart contract template validator 210, a smart contract template creation notifier 212, and a smart contract executor 214. The cloud 204 may include a blockchain smart contract learner 216, a domain ontology registrar 218, a smart contract template discoverer 220, a Natural Language processor (NLP) registrar 222, and a smart contract generator 224. [i.e., the smart contract generator is part of the AI model]; [Note: Padmanabhan, [0088] FIG. 1B depicts another exemplary architecture 101, with additional detail of a blockchain protocol block 160 operating in conjunction with a block validator 192, in accordance with described embodiments.; [0089] In particular, a blockchain protocol block 160 is depicted here to be validated by the block validator 192 of the host organization 110, with the blockchain protocol block including addition detail of its various sub-components, and certain optional elements which may be utilized in conjunction with the blockchain protocol block 160 depending on the particular blockchain protocol being utilized via the blockchain services interface 190.] ).
Motivation to combine same as stated for claim 1.
Regarding claim 3, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 1, and the combination further teaches wherein the ML model includes a large language model (LLM) that interprets the natural language input (Shillingford, Paragraph [0013] teaches a natural language processing system (which may be a subsystem of a smart contract generation system, as described below) may utilize a trained machine learning model, such as the generative pre-trained transformer 3 (GPT-3) autoregressive language model that uses deep structured learning. [Note: here the generative pre-trained transformer 3 (GPT-3) is a large language model (LLM)].).
Regarding claim 5, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 1, and the combination further teaches wherein the transaction corresponds to a smart contract, and the actions correspond to conditions of the smart contract determined based on the natural language input and the contextual information (Shillingford, Paragraph [0029] teaches a smart contract generation system 200 may receive, at 210, a written document or audio exchange containing contract terms [i.e., actions]. The system may extract, at 212, terms, such as contract terms, from the received document or audio exchange using a natural language processing model (e.g., a machine learning-based model, such as a fine-tuned adaptation of GPT-3 or BERT model). The system may identify, at 214, chaincodes within a library of chaincodes that correspond to each extracted contract term… The system may then assemble, at 216, the individual chaincodes to generate a smart contract to effectuate the original contract terms using a smart contract in a blockchain.; Kumar, Paragraph [0007] teaches a method for automatically generating personalized smart contracts is disclosed.; Kumar, Paragraph [0021] teaches the system 100 generates context aware smart contracts, each of which is unique to a particular transaction.; Kumar, Paragraph [0022] further teaches the requirements [i.e., actions] and context for a particular transaction may be provided by one of stakeholders 106-1 to 106-n [i.e. natural language input], collectively referred to as a plurality of stakeholders 106…The context, for example, may include, but are not limited to location of usage, person using it, or a type associated with an asset.).
Motivation to combine same as stated for claim 1.
Regarding claim 6, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 1, and the combination further teaches wherein the transaction is associated with a sequence of related transactions that instantiate and modify a state of the ML model, and wherein each sequence is assigned a unique identifier isolated to the version of the ML model and from other transaction sequences (Padmanabhan, Paragraph [0101] teaches various standard of proofs 165 may utilized pursuant to the particular blockchain protocol chosen, such as proof of work, hash value requirements, proof of stake, a key, or some other indicator such as a consensus, or proof of consensus. Where consensus-based techniques are utilized, the blockchain consensus manager 191 provides consensus management on behalf of the host organization 110, however, the host organization 110 may be operating only as one of many nodes for a given blockchain protocol which is accessed by the host organization 110 via the blockchain services interface 190 or alternatively, the host organization 110 may define and provide a particular blockchain protocol as a cloud based service to customers and subscribers (and potentially to non-authenticated public node participants), via the blockchain services interface 190. Such a standard of proof 165 may be applied as a rule that requires a hash value to be less than the proof standard, more than the proof standard, or may require a specific bit sequence (such as 10 zeros, or a defined binary sequence) or a required number of leading or trailing zeroes (e.g., such as a hash of an input which results in 20 leading or trailing zeros, which is computationally infeasible to provide without a known valid input). [Note: the hash value and/or the key, in Padmanabhan, understood to read on a unique identifier assigned to the sequence]; Padmanabhan, Paragraph [0102] further teaches the hash algorithms used for the prior hash 161, the payload hash 163, or the authorized hashes 168 may all be of the same type or of different types, depending on the particular blockchain protocol implementation.; Padmanabhan Paragraph [0105], further teaches the state ledger 159 maintains the status of the accessible blockchains and any connection or non-connection states while the history 161 block maintains a transaction history and logging for the platform. [Note the accessible blockchains and connection or non-connection states the history block maintaining a transaction history understood to read on the “sequence”] The integration platform layer 158 provides an interface to other components within the host organization 110 to interface with the components of the blockchain metadata definition manager 196 while the access control layer 162 is described in greater detail below, but provides certain access rights and restrictions for private and permissioned blockchains that are not fully open to public access.; Padmanabhan, Paragraph [0139] teaches host organization users may interact with such accessible cloud platforms 156 to create and record data, and where appropriate, data and events may be pushed back into the blockchain through configured virtual objects which communicate with the REST API to write information into the blockchain or to reference information in the blockchain or to update state information for managed events within the blockchain.; receiving a request to register the AI model with an audit record keeping service; Padmanabhan, Paragraph [0055] teaches receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.; Padmanabhan [0463] teaches according to another embodiment, multi-tenant support is provided by the immutable and audit compliant record keeping for such transactions. According to such an embodiment, the transactions include data which describes a collection of data descriptors from the following exemplary list: what decision was made by the AI trained model, what version of the AI model made the decision, what decision was made, what collection of training data was utilized to train the AI model, any confidence score or predictive score output by the AI model, what Einstein cloud platform features or GUIs were utilized, and AI intermediate node decision points triggered to lead to the output decision by the Einstein cloud platform.; Padmanabhan [0469] teaches consider another exemplary scenario where the same Bank A and Bank B, each again being part of Blockchain, have their data once again shared based on a consent mechanism [i.e., the consent mechanism was shown in [0101] to include a hash value requirement or a key – reading on an identifier assigned to the sequence], however, in this instance, the Einstein cloud platform makes a score or decision for a consumer of the bank based on the shared data subsequent to the Banks A and B each having registered with the Einstein cloud platform's EinsChain service, thus enabling full audit tracking and transparency. Now, the decision and action is stored by transacting a new asset onto the blockchain through the blockchain services interface linked with the EinsChain service, thus immutably storing and preserving the decisions, the decision factors, and other relevant information for the purposes of future reference or a future audit. Should the Banks A or B conduct an audit, or be subjected to Audit, then via the Einstein cloud platform's EinsChain service, they can recall that data through an API or through a point and click based GUI to retrieve not just the record of the decision, but the associated data supporting that decision, as noted above, such as the AI model utilized, the training data collection used for training the model, intermediate nodes of the AI model fired in support of that decision, what decision was rendered, confidence scores, predictive scores, etc. [Note: the audit process through the EinsChain service allows the users to retrieve not just the records of the decition but which AI model was utilized reading on a “isolated to the version of the ML model and from other transaction sequences”, as claimed).
Motivation to combine same as stated in claim 1.
Regarding claim 7, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 1, and the combination further teaches wherein the transaction includes at least one of a fee, a free form field comprising the natural language input, and a sequence identification (ID) comprising a unique identifier associated with a set of transactions (Shillingford, Paragraph [0015] teaches payment terms – reading on “fee” as claimed).
Regarding claim 10, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 1, and the combination further teaches wherein the ML model is trained on at least a natural language used to specify the transaction (Shillingford, Paragraph [0015] teaches according to various embodiments, extraction of the terms may be performed using a machine learning model trained for a specific type of contract, for a wider range of general contracts, or for more generalized natural language.; Shillingford, Paragraph [0020] further teaches In some embodiments, the natural language processing system (or subsystem) may be created by fine-tuning an existing machine learning natural language processing model trained with a general English language dataset (or other target language). That is, the natural language processing system or subsystem configured to convert English language contract terms to chaincodes did not previously exist. However, utilizing “transfer learning,” existing natural language processing models trained with general or generic English language datasets can be trained with fine-tuned datasets with an emphasis on contract terms, legal terms, programming languages, scripts, distributed ledger languages and protocols, blockchain protocols, and/or other materials to support conversion of contract terms to chaincodes for execution on a blockchain or ledger-based platform.; Shillingford, Paragraph [0013] teaches A natural language processing system (which may be a subsystem of a smart contract generation system, as described below) may utilize a trained machine learning model, such as the generative pre-trained transformer 3 (GPT-3) [i.e., an LLM]).
Regarding claim 11, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 1, and the combination further teaches:
wherein determining the intent and contextual information includes:
interpreting the transaction using multiple LLMs (Padmanabhan [0055] teaches receiving a request to register the AI model with an audit record keeping service; receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.; Padmanabhan [0458] further teaches with use of smart contracts which execute via blockchains that might get triggered based on the actions observed or changes observed within the blockchain, it is possible that such process flows could result in an audit mess and due to complex technologies which lead to the decisions and increasingly difficult tracking, especially tracking of those decisions which are made via AI trained models. [i.e. via “multiple” AI models]; [0460] Compliance, Customer/Consumer transparency, communication, and collaboration all may therefore be further improved through the use of a multi tenant blockchain platform for managing the Einstein platform's output decisions through the use of using distributed ledger technology.; Padmanabhan [0473] further teaches , any platform, including those utilizing AI based models or utilizing deep learning, etc., will ultimately make recommendations, predications, decisions, and take actions, which if adopted and accepted by the business using such platforms, generates data which is potentially important to capture and immutably record via the EinsChain service in a distributed ledger, such as the blockchain upon which the businesses are participating nodes. [note: Padmanabhan [0473] teaches utilizing AI based models understood as “multiple” AI models]); and
based on at least two of the multiple LLMs generating having different interpretations of the transaction, initiating a resolution protocol that includes reverting the transaction (Padmanabhan [0097], teaches the blockchain protocol certification 166 defines the required size and/or data structure of the block payload 169 as well as certifying compliance with a particular blockchain protocol implementation, and thus, certifies the blockchain protocol block subscribes to, implements, and honors the particular requirements and configuration options for the indicated blockchain protocol. The blockchain protocol certification 166 may also indicate a version of a given blockchain protocol and the blockchain protocol may permit limited backward and forward compatibility for blocks before nodes will begin to reject new blockchain protocol blocks for non-compliance.; Padmanabhan, Paragraph [0098] teaches Certain blockchain protocols use multiple different block types 167, all of which may have varying payloads, but have a structure which is known a priori according to the blockchain protocol utilized, the declared block type 167, and the blockchain protocol certification 166 certifying compliance with such requirements. Non-compliance or an invalid block type or an unexpected structure or payload for a given declared block type 167 will result in the rejection of that block by network nodes. [Note: Non-compliance or invalid block type or an unexpected structure as taught in [0098] understood to read on interpreting as “having different interpretations”]; Padmanabhan, Paragraph [0112] further teaches if any established network member trusts host organization as the central party, then the system and architecture works for that particular established network member. Notably, however, the established network members must place their trust into a third party, in this case the host organization 110. If doing so is not possible, or not permissible based on the various data security requirements, regulations, or other concerns, then the Distributed Ledger Technology (DLT) which requires consensus by the distributed nodes , as managed by the blockchain consensus manger 191 is more appropriate for those parties.; Padmanabhan, Paragraph [0449] further teaches the Einstein cloud platform 889 utilizes natural language processing to extract meaning from every piece of text and utilizes natural language processing (NLP) to find linguistic patterns you can use to answer questions, respond to requests, and identify conversations about your brand across the web.; Padmanabhan, Paragraph [0450] further teaches the Einstein cloud platform 889 utilizes an Einstein Language which permits users to understand how customers feel, automatically route inquiries, and streamline your workflows. Build natural language processing into your apps to classify the underlying intent and sentiment in a body of text. Functions implement Einstein scanning of content and to provide a synopsis for a Salesforce user to follow.)
[EXAMINER NOTE: Padmanabhan teaches all of the limitations of claim 11, however it does not distinctly disclose the AI models as large language models (i.e., LLMs). However, Shillingford was shown to teach LLMs which are a type of MLMs].
Motivation to combine same as stated in claim 1.
Regarding claim 12, Shillingford teaches a system for implementing transactions in a blockchain platform (Shillingford, Paragraph [0013] teaches A natural language processing system (which may be a subsystem of a smart contract generation system; Note: for implementing transactions in a blockchain platform is being understood as intended use language not limiting the structure of the claim invention, See MPEP 2111.02(II)), comprising:
one or more processors (Shillingford, Paragraph [0021] teaches infrastructure that can be used with embodiments disclosed herein is already available, such as general-purpose computers, …A computer may include a processor, such as a microprocessor, microcontroller, logic circuitry, or the like. The processor may include a special purpose processing device, such as an ASIC, PAL, PLA, PLD, Field Programmable Gate Array, or another customized or programmable device.); and
a memory comprising instructions stored thereon, which when executed by the one or more processors (Shillingford, Paragraph [0021] further teaches the computer may also include a computer-readable storage device, such as non-volatile memory, static RAM, dynamic RAM, ROM, CD-ROM, disk, tape, magnetic, optical, flash memory, or another computer-readable storage medium.), causes the one or more processors to perform:
receiving a natural language input specifying a transaction to be performed on a blockchain (Shillingford, Paragraph [0029] teaches a smart contract generation system 200 may receive, at 210, a written document or audio exchange containing contract terms. The system may extract, at 212, terms, such as contract terms, from the received document or audio exchange using a natural language processing model (e.g., a machine learning-based model, such as a fine-tuned adaptation of GPT-3 or BERT model). The system may identify, at 214, chaincodes within a library of chaincodes that correspond to each extracted contract term… The system may then assemble, at 216, the individual chaincodes to generate a smart contract to effectuate the original contract terms using a smart contract in a blockchain.);
…, determining actions corresponding to the natural language input using the LLM (Shillingford, Paragraph [0031] a system receives, at 220, a written document (e.g., structured or unstructured) and/or an audio file that contains contract terms. The written document or audio file may be, for example, a written contract, a high-level term sheet, email correspondence, voice records of a deal between two or more parties, a single party document such as a will or trust, and/or another document that specifies actions to be taken with respect to one or more parties in response to triggering events or detectable “states.” The system may, according to any of the embodiments described herein, extract, at 222, contract terms using various natural language processing (NLP) techniques.; Shillingford, Paragraph [0013] teaches a natural language processing system (which may be a subsystem of a smart contract generation system, as described below) may utilize a trained machine learning model, such as the generative pre-trained transformer 3 (GPT-3) autoregressive language model that uses deep structured learning. [Note: here the generative pre-trained transformer 3 (GPT-3) is a large language model (LLM)]); and
based on the confirmed actions, executing the transaction on the blockchain based on the actions (Shillingford, Paragraph [0033] teaches the smart contract generation system assembles the chaincodes of the discrete contract terms together with the smart contract units associated with the compound contract terms to generate, at 236, a smart contract. The auto-executing smart contract can be stored to a blockchain platform for the irrevocable and immutable execution of the original terms of the received contract.; Shillingford, Paragraph [0019] teaches the contracting parties and/or their attorneys may review the functionality of the chaincodes generated to confirm that the chaincodes accurately correlate to the natural language contract terms.; Shillingford [0034] further teaches The chaincodes and smart contract units may be assembled, at 236, to generate a complete smart contract. In some embodiments, the system may then test, at 238, the smart contract against the original contract (e.g., the system's understanding of the original contract as processed by a natural language processing algorithm) to confirm that the functionality is equivalent.); and
However, Shillingford does not distinctly disclose:
based on the natural language input, determining, an intent and contextual information associated with the transaction based on the natural language input using a large language model (LLM), wherein a version of the ML model to be used is specified in the transaction;
based on the intent and the contextual information determining actions corresponding to the natural language input
generating, using the version of the ML model, a natural language output describing the determined actions for user confirmation;
based on a plurality of ML models determining divergent actions from the natural language input, initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless, Kumar teaches:
based on the natural language input, determining an intent and contextual information associated with the transaction using a machine learning (ML) model, … (Kumar, Paragraph [0040] teaches the smart contract creating device 108 processes a plurality of contract documents created in natural language [i.e., teaches natural language input] and associated with the plurality of assets. Thereafter, in response to the processing, Natural Language Processing (NLP) is performed based on an Artificial Intelligence (Al) model [i.e., teaches machine learning model] to generate a smart contract template for the current asset.; Paragraph [0007] teaches a method for automatically generating personalized smart contracts is disclosed [i.e., smart contracts teaches transactions].; Kumar, Paragraph [0021] teaches the system 100 generates context aware smart contracts, each of which is unique to a particular transaction.; Kumar, Paragraph [0022] further teaches the requirements [i.e., actions] and context for a particular transaction may be provided by one of stakeholders 106-1 to 106-n [i.e., teaches contextual information and natural language input], collectively referred to as a plurality of stakeholders 106; Kumar, Paragraph [0045] teaches at step 314, the smart contract creating device 108 may receive a plurality of details from the stakeholder [i.e., natural language input] of the current in addition to the plurality of asset attributes from the current asset. At step 316, the smart contract creating device 108 extracts a context and a plurality of features from the plurality of details received from the stakeholder and the plurality of asset attributes received from the current asset. At step 318, the smart contract creating device 108 populates the current smart contract template based on the context and the plurality of features to generate a current smart contract for the current asset.; Kumar, Paragraph [0068] further teaches each of the smart contract templates 602 and 604 include input parameters and business rules [i.e., teaches intent]);
based on the intent and the contextual information determining actions corresponding to the natural language input using the ML model (Kumar, Paragraph [0007] teaches a method for automatically generating personalized smart contracts is disclosed.; Kumar, Paragraph [0021] teaches the system 100 generates context aware smart contracts, each of which is unique to a particular transaction.; Kumar, Paragraph [0022] further teaches the requirements [i.e., teaches determining actions, as claimed] and context for a particular transaction may be provided by one of stakeholders 106-1 to 106-n [i.e. natural language input], collectively referred to as a plurality of stakeholders 106…The context, for example, may include, but are not limited to location of usage, person using it, or a type associated with an asset.; Kumar, Paragraph [0045] teaches at step 314, the smart contract creating device 108 may receive a plurality of details from the stakeholder [i.e., natural language input] of the current in addition to the plurality of asset attributes from the current asset. At step 316, the smart contract creating device 108 extracts a context and a plurality of features from the plurality of details received from the stakeholder and the plurality of asset attributes received from the current asset. At step 318, the smart contract creating device 108 populates the current smart contract template based on the context and the plurality of features to generate a current smart contract for the current asset. As a result, after generation of the smart contract template, the smart contract creating device 108 fills in the recommended values for each of the parameters that is very specific to each transaction, context, asset and stakeholder.; Kumar, Paragraph [0068] further teaches in FIG. 6, a smart contract template 602 associated with the asset category of backhoe loader and a smart contract template 604 associated with the asset category of broad paper machines is depicted. Each of the smart contract templates 602 and 604 include input parameters and business rules [i.e., teaching intent].; Kumar, Paragraph [0040] teaches the smart contract creating device 108 processes a plurality of contract documents created in natural language and associated with the plurality of assets. Thereafter, in response to the processing, Natural Language Processing (NLP) is performed based on an Artificial Intelligence (Al) model [i.e., teaching using ML model] to generate a smart contract template for the current asset.);
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford, with the generation of context aware smart contracts, as taught by Kumar, in order to provide a more personalized, dynamic and deployable smart contract that is unique for an asset, a user, and a transaction. (Kumar, Paragraph [0050])
However the combination does not distinctly disclose:
…, wherein a version of the ML model to be used is specified in the transaction;
generating, using the version of the ML model, a natural language output describing the determined actions for user confirmation;
based on a plurality of ML models determining divergent actions from the natural language input, initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless Padmanabhan teaches:
…, wherein a version of the ML model to be used is specified in the transaction (Padmanabhan, Paragraph [0055] teaches receiving a request to register the AI model with an audit record keeping service; receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.; Padmanabhan [0463] further teaches the transactions include data which describes a collection of data descriptors from the following exemplary list: what decision was made by the AI trained model, what version of the AI model made the decision, what decision was made, what collection of training data was utilized to train the AI model, any confidence score or predictive score output by the AI model, what Einstein cloud platform features or GUIs were utilized, and AI intermediate node decision points triggered to lead to the output decision by the Einstein cloud platform.
Padmanabhan [0490] further teaches it is therefore important that the precise details of that AI model be recorded and tracked for the purposes of having an audit trail, in the event that a customer, the business, administrator, etc., seeks to understand what AI model was utilized to make a decision (e.g., such as a credit acceptance or denial decision), as well as precisely what version of that AI model was utilized.
Padmanabhan [0621] further teaches according to such an embodiment, the system 1301 is further operable to execute instructions for receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.);
generating, using the version of the ML model, a natural language output describing the determined actions for user confirmation (Padmanabhan, Paragraph [0055] teaches receiving a request to register the AI model with an audit record keeping service; receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.; Padmanabhan, Paragraph [0158] further teaches a Simplified Payment Verification (SPV) proof 181 associated with the parent blockchain 188 asset is generated as the output and communicated to the sidechain 189. The SPV proof may include a threshold level of work, and the generating may take place over a predetermined period of time, which may also be referred to as a confirmation period 152. The confirmation period of a transfer between chains may be a duration for which a coin, token, or other exchanged value is locked on the parent blockchain 188 before may successfully be transferred to the sidechain 189 pursuant to the send SPV-locked output operation 127.; Padmanabhan, Paragraph [0159] further teaches consider for instance an exemplary confirmation period which may be on the order of 1-2 days. The confirmation period may be implemented, in such an example, as a per-sidechain security parameter, which trades off cross-chain transfer speeds in exchange for greater security. Other confirmation periods which are much shorter may be utilized where sufficiently difficult proof of work conditions are effectuated so as to ensure adequate security so as to protect the integrity of both blockchains and negate the potential for fraudulent transactions.; Padmanabhan, Paragraph [0160] further teaches after creating the output on the parent blockchain 188, the user waits out the confirmation period, meanwhile, intra-chain transfers 153 continue to occur. Subsequent to waiting out the confirmation period 122, a transaction is then created on the sidechain 189 referencing the output from the parent blockchain 188.);
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford in view of Kumar, to further include the systems and methods for implementing a multi-tenant blockchain platform using distributed ledger technology, as taught by Padmanabhan, in order to provide a shared ledger that provides an audit trail which is immutable by any party, including by the host organization, and thus, provides greater security, transparency, and assurance than a standard audit trail offered by competing solutions. Added value is thus brought to the tenants and customer organizations when utilizing the shared ledger when compared with a standard centralized system. Further still, because the shared ledger is multi-tenant aware (e.g., each tenant or customer organization may utilize its own instance of the shared ledger) and metadata driven, with executable smart contracts via triggers, there are multiple advantages for the host organization's tenant subscribers, above and beyond the platform benefits offered by the host organization. (Padmanabhan, Paragraphs [0117] and [0118])
However, the combination does not distinctly disclose based on a plurality of ML models producing divergent actions from the natural language input, initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless, Yang teaches based on a plurality of ML models producing divergent actions from the natural language input,… (Yang, Figure 2, teaches plurality of LLM agents producing divergent actions with varying confidence values from the natural language prompt; Yang, Section 3.1, further teaches we obtain a set of unique and diverse answers (“stances”) using a GPT-3.5 judge. This constitutes the output of the first stage: semantically unique stances each with a corresponding frequency and aggregated mean confidence; Yang, Section 3.2 further teaches the diverse stances from Stage 1 are assigned to the general agents as deliberators).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford in view of Kumar and Padmanabhan, to further include the plurality of LLM agent stance generation, as taught by Yang, in order to demonstrate the effectiveness of collaborative calibration on generative QA tasks across various domains showing its potential in harnessing the rationalization of collectively calibrated confidence assessments and improving the reliability of model predictions. (Yang, Abstract and pg. 2, par. 2)
However, the combination does not distinctly disclose:
…initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless, Jumnongsaksub teaches …initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state (Jumnongsaksub, pg. 3, teaches when the EVM detects a fatal error, it halts the current execution, reverts the global state, and marks the transaction as failed).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford in view of Kumar, Padmanabhan and Yang, to further include the algorithm to detect smart contract methods with bad transaction behavior, as taught by Jumnongsaksub, in order to reduce the number of failed transactions on the Ethereum blockchain by helping users to avoid sending transactions that will result in failure. This will improve the transaction processing performance of the overall network since transactions that are likely to fail are prevented and most of the transactions selected by miners for validation are successful transactions. Furthermore, we can reduce the overall storage of the blockchain by storing fewer failed transactions. (Jumnongsaksub, pg. 3, par. 2 and pg. 4, par. 1)
Regarding claim 13, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 12, and the combination further teaches wherein the ML is embedded within validator nodes of a blockchain network (Kumar, Paragraph [0046] teaches the smart contract creating device 108 validates the current smart contract in order to verify if the created smart contract template suits the current asset as well as the stakeholder (asset owner); Kumar, Paragraph [0032] teaches in absence of smart contract templates based upon asset domain ontology, the NLP registrar 222 is configured to create smart contract templates based on machine learning techniques from generalized English agreement copies associated with similar assets.; Kumar, Fig. 2 teaches smart contract template validator 210; Kumar, Paragraph [0030] teaches the smart contract template validator 210 is configured to validate the smart contract after generation. Once the personalized smart contract template is generated, the smart contract templates are validated to examine if the generated templates suit the asset and/or asset owner.; Kumar, Paragraph [0053] teaches referring now to FIGS. 5A and 5B, a flowchart of a method for automatically generating personalized smart contracts in different scenarios is illustrated, in accordance with an embodiment. At step 502, the smart contract creating device 108 identifies a plurality of asset attributes associated with a current asset within a blockchain network.; Kumar, Figs 5A and 5B.; [Note: Padmanabhan, [0088] FIG. 1B depicts another exemplary architecture 101, with additional detail of a blockchain protocol block 160 operating in conjunction with a block validator 192, in accordance with described embodiments.; [0089] In particular, a blockchain protocol block 160 is depicted here to be validated by the block validator 192 of the host organization 110, with the blockchain protocol block including addition detail of its various sub-components, and certain optional elements which may be utilized in conjunction with the blockchain protocol block 160 depending on the particular blockchain protocol being utilized via the blockchain services interface 190.]).
Motivation to combine same as stated for claim 12.
Regarding claim 15, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 12, and the combination further teaches wherein the transaction corresponds to a smart contract, and the actions correspond to conditions of the smart contract determined based on the natural language input and the contextual information (Shillingford, Paragraph [0029] teaches a smart contract generation system 200 may receive, at 210, a written document or audio exchange containing contract terms [i.e., actions]. The system may extract, at 212, terms, such as contract terms, from the received document or audio exchange using a natural language processing model (e.g., a machine learning-based model, such as a fine-tuned adaptation of GPT-3 or BERT model). The system may identify, at 214, chaincodes within a library of chaincodes that correspond to each extracted contract term… The system may then assemble, at 216, the individual chaincodes to generate a smart contract to effectuate the original contract terms using a smart contract in a blockchain.; Kumar, Paragraph [0007] teaches a method for automatically generating personalized smart contracts is disclosed.; Kumar, Paragraph [0021] teaches the system 100 generates context aware smart contracts, each of which is unique to a particular transaction.; Kumar, Paragraph [0022] further teaches the requirements [i.e., actions] and context for a particular transaction may be provided by one of stakeholders 106-1 to 106-n [i.e. natural language input], collectively referred to as a plurality of stakeholders 106…The context, for example, may include, but are not limited to location of usage, person using it, or a type associated with an asset.).
Motivation to combine same as stated for claim 1.
Regarding claim 16, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 12, and the combination further teaches wherein the transaction is associated with a sequence of related transactions that instantiate and modify a state of the LLM, and wherein each sequence is assigned a unique identifier isolated to the version of the ML model and from other transaction sequences ((Padmanabhan, Paragraph [0101] teaches various standard of proofs 165 may utilized pursuant to the particular blockchain protocol chosen, such as proof of work, hash value requirements, proof of stake, a key, or some other indicator such as a consensus, or proof of consensus. Where consensus-based techniques are utilized, the blockchain consensus manager 191 provides consensus management on behalf of the host organization 110, however, the host organization 110 may be operating only as one of many nodes for a given blockchain protocol which is accessed by the host organization 110 via the blockchain services interface 190 or alternatively, the host organization 110 may define and provide a particular blockchain protocol as a cloud based service to customers and subscribers (and potentially to non-authenticated public node participants), via the blockchain services interface 190. Such a standard of proof 165 may be applied as a rule that requires a hash value to be less than the proof standard, more than the proof standard, or may require a specific bit sequence (such as 10 zeros, or a defined binary sequence) or a required number of leading or trailing zeroes (e.g., such as a hash of an input which results in 20 leading or trailing zeros, which is computationally infeasible to provide without a known valid input). [Note: the hash value and/or the key, in Padmanabhan, understood to read on a unique identifier assigned to the sequence]; Padmanabhan, Paragraph [0102] further teaches the hash algorithms used for the prior hash 161, the payload hash 163, or the authorized hashes 168 may all be of the same type or of different types, depending on the particular blockchain protocol implementation.; Padmanabhan Paragraph [0105], further teaches the state ledger 159 maintains the status of the accessible blockchains and any connection or non-connection states while the history 161 block maintains a transaction history and logging for the platform. [Note the accessible blockchains and connection or non-connection states the history block maintaining a transaction history understood to read on the “sequence”] The integration platform layer 158 provides an interface to other components within the host organization 110 to interface with the components of the blockchain metadata definition manager 196 while the access control layer 162 is described in greater detail below, but provides certain access rights and restrictions for private and permissioned blockchains that are not fully open to public access.; Padmanabhan, Paragraph [0139] teaches host organization users may interact with such accessible cloud platforms 156 to create and record data, and where appropriate, data and events may be pushed back into the blockchain through configured virtual objects which communicate with the REST API to write information into the blockchain or to reference information in the blockchain or to update state information for managed events within the blockchain.; receiving a request to register the AI model with an audit record keeping service; Padmanabhan, Paragraph [0055] teaches receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.; Padmanabhan [0463] teaches according to another embodiment, multi-tenant support is provided by the immutable and audit compliant record keeping for such transactions. According to such an embodiment, the transactions include data which describes a collection of data descriptors from the following exemplary list: what decision was made by the AI trained model, what version of the AI model made the decision, what decision was made, what collection of training data was utilized to train the AI model, any confidence score or predictive score output by the AI model, what Einstein cloud platform features or GUIs were utilized, and AI intermediate node decision points triggered to lead to the output decision by the Einstein cloud platform.; Padmanabhan [0469] teaches consider another exemplary scenario where the same Bank A and Bank B, each again being part of Blockchain, have their data once again shared based on a consent mechanism [i.e., the consent mechanism was shown in [0101] to include a hash value requirement or a key – reading on an identifier assigned to the sequence], however, in this instance, the Einstein cloud platform makes a score or decision for a consumer of the bank based on the shared data subsequent to the Banks A and B each having registered with the Einstein cloud platform's EinsChain service, thus enabling full audit tracking and transparency. Now, the decision and action is stored by transacting a new asset onto the blockchain through the blockchain services interface linked with the EinsChain service, thus immutably storing and preserving the decisions, the decision factors, and other relevant information for the purposes of future reference or a future audit. Should the Banks A or B conduct an audit, or be subjected to Audit, then via the Einstein cloud platform's EinsChain service, they can recall that data through an API or through a point and click based GUI to retrieve not just the record of the decision, but the associated data supporting that decision, as noted above, such as the AI model utilized, the training data collection used for training the model, intermediate nodes of the AI model fired in support of that decision, what decision was rendered, confidence scores, predictive scores, etc. [Note: the audit process through the EinsChain service allows the users to retrieve not just the records of the decition but which AI model was utilized reading on a “isolated to the version of the ML model and from other transaction sequences”, as claimed).
Motivation to combine same as stated in claim 12.
Regarding claim 17, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 12, and the combination further teaches wherein the transaction includes at least one of a fee, a free form field comprising the natural language input, and a sequence identification (ID) comprising a unique identifier associated with a set of transactions (Shillingford, Paragraph [0015] teaches payment terms – reading on “fee” as claimed)
Regarding claim 19, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 12, however the combination does not distinctly disclose wherein determining the intent and contextual information includes:
interpreting the transaction using multiple LLMs (Padmanabhan [0055] teaches receiving a request to register the AI model with an audit record keeping service; receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.; Padmanabhan [0458] further teaches with use of smart contracts which execute via blockchains that might get triggered based on the actions observed or changes observed within the blockchain, it is possible that such process flows could result in an audit mess and due to complex technologies which lead to the decisions and increasingly difficult tracking, especially tracking of those decisions which are made via AI trained models. [i.e. via “multiple” AI models]; [0460] Compliance, Customer/Consumer transparency, communication, and collaboration all may therefore be further improved through the use of a multi tenant blockchain platform for managing the Einstein platform's output decisions through the use of using distributed ledger technology.; Padmanabhan [0473] further teaches , any platform, including those utilizing AI based models or utilizing deep learning, etc., will ultimately make recommendations, predications, decisions, and take actions, which if adopted and accepted by the business using such platforms, generates data which is potentially important to capture and immutably record via the EinsChain service in a distributed ledger, such as the blockchain upon which the businesses are participating nodes. [note: Padmanabhan [0473] teaches utilizing AI based models understood as “multiple” AI models]); and
based on at least two of the multiple LLMs generating having different interpretations of the transaction, initiating a resolution protocol that includes reverting the transaction (Padmanabhan [0097], teaches the blockchain protocol certification 166 defines the required size and/or data structure of the block payload 169 as well as certifying compliance with a particular blockchain protocol implementation, and thus, certifies the blockchain protocol block subscribes to, implements, and honors the particular requirements and configuration options for the indicated blockchain protocol. The blockchain protocol certification 166 may also indicate a version of a given blockchain protocol and the blockchain protocol may permit limited backward and forward compatibility for blocks before nodes will begin to reject new blockchain protocol blocks for non-compliance.; Padmanabhan, Paragraph [0098] teaches Certain blockchain protocols use multiple different block types 167, all of which may have varying payloads, but have a structure which is known a priori according to the blockchain protocol utilized, the declared block type 167, and the blockchain protocol certification 166 certifying compliance with such requirements. Non-compliance or an invalid block type or an unexpected structure or payload for a given declared block type 167 will result in the rejection of that block by network nodes. [Note: Non-compliance or invalid block type or an unexpected structure as taught in [0098] understood to read on interpreting as “having different interpretations”]; Padmanabhan, Paragraph [0112] further teaches if any established network member trusts host organization as the central party, then the system and architecture works for that particular established network member. Notably, however, the established network members must place their trust into a third party, in this case the host organization 110. If doing so is not possible, or not permissible based on the various data security requirements, regulations, or other concerns, then the Distributed Ledger Technology (DLT) which requires consensus by the distributed nodes , as managed by the blockchain consensus manger 191 is more appropriate for those parties.; Padmanabhan, Paragraph [0449] further teaches the Einstein cloud platform 889 utilizes natural language processing to extract meaning from every piece of text and utilizes natural language processing (NLP) to find linguistic patterns you can use to answer questions, respond to requests, and identify conversations about your brand across the web.; Padmanabhan, Paragraph [0450] further teaches the Einstein cloud platform 889 utilizes an Einstein Language which permits users to understand how customers feel, automatically route inquiries, and streamline your workflows. Build natural language processing into your apps to classify the underlying intent and sentiment in a body of text. Functions implement Einstein scanning of content and to provide a synopsis for a Salesforce user to follow.)
Regarding claim 20, Shillingford teaches a non-transitory computer-readable storage medium comprising instructions stored thereon, which when executed by one or more processors (Shillingford, Paragraph [0025] teaches FIG. 1 illustrates an example of a smart contract generation system 100 for implementing the various processes and methods described herein, according to various embodiments of the present disclosure. As illustrated, the system 100 may include a bus 118 that connects a processor 120, a memory 122, and a network interface 124 to a computer-readable storage medium 102, such as a non-transitory computer-readable storage medium.; See Fig. 1), cause the one or more processors to perform operations for implementing transactions in a blockchain platform (Note: for implementing transactions in a blockchain platform is being understood as intended use language not limiting the structure of the claim invention, See MPEP 2111.02(II)), comprising:
receiving a natural language input specifying a transaction to be performed on a blockchain (Shillingford, Paragraph [0029] teaches a smart contract generation system 200 may receive, at 210, a written document or audio exchange containing contract terms. The system may extract, at 212, terms, such as contract terms, from the received document or audio exchange using a natural language processing model (e.g., a machine learning-based model, such as a fine-tuned adaptation of GPT-3 or BERT model). The system may identify, at 214, chaincodes within a library of chaincodes that correspond to each extracted contract term… The system may then assemble, at 216, the individual chaincodes to generate a smart contract to effectuate the original contract terms using a smart contract in a blockchain.);
…, determining actions corresponding to the natural language input using the LLM (Shillingford, Paragraph [0031] a system receives, at 220, a written document (e.g., structured or unstructured) and/or an audio file that contains contract terms. The written document or audio file may be, for example, a written contract, a high-level term sheet, email correspondence, voice records of a deal between two or more parties, a single party document such as a will or trust, and/or another document that specifies actions to be taken with respect to one or more parties in response to triggering events or detectable “states.” The system may, according to any of the embodiments described herein, extract, at 222, contract terms using various natural language processing (NLP) techniques.; Shillingford, Paragraph [0013] teaches a natural language processing system (which may be a subsystem of a smart contract generation system, as described below) may utilize a trained machine learning model, such as the generative pre-trained transformer 3 (GPT-3) autoregressive language model that uses deep structured learning. [Note: here the generative pre-trained transformer 3 (GPT-3) is a large language model (LLM)]); and
based on the confirmed actions, executing the transaction on the blockchain based on the actions (Shillingford, Paragraph [0033] teaches the smart contract generation system assembles the chaincodes of the discrete contract terms together with the smart contract units associated with the compound contract terms to generate, at 236, a smart contract. The auto-executing smart contract can be stored to a blockchain platform for the irrevocable and immutable execution of the original terms of the received contract.; Shillingford, Paragraph [0019] teaches the contracting parties and/or their attorneys may review the functionality of the chaincodes generated to confirm that the chaincodes accurately correlate to the natural language contract terms.; Shillingford [0034] further teaches The chaincodes and smart contract units may be assembled, at 236, to generate a complete smart contract. In some embodiments, the system may then test, at 238, the smart contract against the original contract (e.g., the system's understanding of the original contract as processed by a natural language processing algorithm) to confirm that the functionality is equivalent.); and
However, Shillingford does not distinctly disclose:
based on the natural language input, determining, an intent and contextual information associated with the transaction based on the natural language input using a large language model (LLM), wherein a version of the ML model to be used is specified in the transaction;
based on the intent and the contextual information determining actions corresponding to the natural language input
generating, using the version of the ML model, a natural language output describing the determined actions for user confirmation;
based on a plurality of ML models producing divergent actions from the natural language input, initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless, Kumar teaches:
based on the natural language input, determining an intent and contextual information associated with the transaction using a machine learning (ML) model, … (Kumar, Paragraph [0040] teaches the smart contract creating device 108 processes a plurality of contract documents created in natural language [i.e., teaches natural language input] and associated with the plurality of assets. Thereafter, in response to the processing, Natural Language Processing (NLP) is performed based on an Artificial Intelligence (Al) model [i.e., teaches machine learning model] to generate a smart contract template for the current asset.; Paragraph [0007] teaches a method for automatically generating personalized smart contracts is disclosed [i.e., smart contracts teaches transactions].; Kumar, Paragraph [0021] teaches the system 100 generates context aware smart contracts, each of which is unique to a particular transaction.; Kumar, Paragraph [0022] further teaches the requirements [i.e., actions] and context for a particular transaction may be provided by one of stakeholders 106-1 to 106-n [i.e., teaches contextual information and natural language input], collectively referred to as a plurality of stakeholders 106; Kumar, Paragraph [0045] teaches at step 314, the smart contract creating device 108 may receive a plurality of details from the stakeholder [i.e., natural language input] of the current in addition to the plurality of asset attributes from the current asset. At step 316, the smart contract creating device 108 extracts a context and a plurality of features from the plurality of details received from the stakeholder and the plurality of asset attributes received from the current asset. At step 318, the smart contract creating device 108 populates the current smart contract template based on the context and the plurality of features to generate a current smart contract for the current asset.; Kumar, Paragraph [0068] further teaches each of the smart contract templates 602 and 604 include input parameters and business rules [i.e., teaches intent]);
based on the intent and the contextual information determining actions corresponding to the natural language input using the ML model (Kumar, Paragraph [0007] teaches a method for automatically generating personalized smart contracts is disclosed.; Kumar, Paragraph [0021] teaches the system 100 generates context aware smart contracts, each of which is unique to a particular transaction.; Kumar, Paragraph [0022] further teaches the requirements [i.e., teaches determining actions, as claimed] and context for a particular transaction may be provided by one of stakeholders 106-1 to 106-n [i.e. natural language input], collectively referred to as a plurality of stakeholders 106…The context, for example, may include, but are not limited to location of usage, person using it, or a type associated with an asset.; Kumar, Paragraph [0045] teaches at step 314, the smart contract creating device 108 may receive a plurality of details from the stakeholder [i.e., natural language input] of the current in addition to the plurality of asset attributes from the current asset. At step 316, the smart contract creating device 108 extracts a context and a plurality of features from the plurality of details received from the stakeholder and the plurality of asset attributes received from the current asset. At step 318, the smart contract creating device 108 populates the current smart contract template based on the context and the plurality of features to generate a current smart contract for the current asset. As a result, after generation of the smart contract template, the smart contract creating device 108 fills in the recommended values for each of the parameters that is very specific to each transaction, context, asset and stakeholder.; Kumar, Paragraph [0068] further teaches in FIG. 6, a smart contract template 602 associated with the asset category of backhoe loader and a smart contract template 604 associated with the asset category of broad paper machines is depicted. Each of the smart contract templates 602 and 604 include input parameters and business rules [i.e., teaching intent].; Kumar, Paragraph [0040] teaches the smart contract creating device 108 processes a plurality of contract documents created in natural language and associated with the plurality of assets. Thereafter, in response to the processing, Natural Language Processing (NLP) is performed based on an Artificial Intelligence (Al) model [i.e., teaching using ML model] to generate a smart contract template for the current asset.);
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford, with the generation of context aware smart contracts, as taught by Kumar, in order to provide a more personalized, dynamic and deployable smart contract that is unique for an asset, a user, and a transaction. (Kumar, Paragraph [0050])
However the combination does not distinctly disclose:
…, wherein a version of the ML model to be used is specified in the transaction;
generating, using the version of the ML model, a natural language output describing the determined actions for user confirmation;
based on a plurality of ML models producing divergent actions from the natural language input, initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless Padmanabhan teaches:
…, wherein a version of the ML model to be used is specified in the transaction (Padmanabhan, Paragraph [0055] teaches receiving a request to register the AI model with an audit record keeping service; receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.; Padmanabhan [0463] further teaches the transactions include data which describes a collection of data descriptors from the following exemplary list: what decision was made by the AI trained model, what version of the AI model made the decision, what decision was made, what collection of training data was utilized to train the AI model, any confidence score or predictive score output by the AI model, what Einstein cloud platform features or GUIs were utilized, and AI intermediate node decision points triggered to lead to the output decision by the Einstein cloud platform.
Padmanabhan [0490] further teaches it is therefore important that the precise details of that AI model be recorded and tracked for the purposes of having an audit trail, in the event that a customer, the business, administrator, etc., seeks to understand what AI model was utilized to make a decision (e.g., such as a credit acceptance or denial decision), as well as precisely what version of that AI model was utilized.
Padmanabhan [0621] further teaches according to such an embodiment, the system 1301 is further operable to execute instructions for receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.);
generating, using the version of the ML model, a natural language output describing the determined actions for user confirmation (Padmanabhan, Paragraph [0055] teaches receiving a request to register the AI model with an audit record keeping service; receiving a transaction at the blockchain; issuing a decision by the AI model to accept or reject the transaction; and transacting a new asset onto the blockchain recording the decision to accept or reject the transaction and the data set utilized to train the AI model and a version of the AI model.; Padmanabhan, Paragraph [0158] further teaches a Simplified Payment Verification (SPV) proof 181 associated with the parent blockchain 188 asset is generated as the output and communicated to the sidechain 189. The SPV proof may include a threshold level of work, and the generating may take place over a predetermined period of time, which may also be referred to as a confirmation period 152. The confirmation period of a transfer between chains may be a duration for which a coin, token, or other exchanged value is locked on the parent blockchain 188 before may successfully be transferred to the sidechain 189 pursuant to the send SPV-locked output operation 127.; Padmanabhan, Paragraph [0159] further teaches consider for instance an exemplary confirmation period which may be on the order of 1-2 days. The confirmation period may be implemented, in such an example, as a per-sidechain security parameter, which trades off cross-chain transfer speeds in exchange for greater security. Other confirmation periods which are much shorter may be utilized where sufficiently difficult proof of work conditions are effectuated so as to ensure adequate security so as to protect the integrity of both blockchains and negate the potential for fraudulent transactions.; Padmanabhan, Paragraph [0160] further teaches after creating the output on the parent blockchain 188, the user waits out the confirmation period, meanwhile, intra-chain transfers 153 continue to occur. Subsequent to waiting out the confirmation period 122, a transaction is then created on the sidechain 189 referencing the output from the parent blockchain 188.);
However, the combination does not distinctly disclose based on a plurality of ML models producing divergent actions from the natural language input, initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless, Yang teaches based on a plurality of ML models producing divergent actions from the natural language input,… (Yang, Figure 2, teaches plurality of LLM agents producing divergent actions with varying confidence values from the natural language prompt; Yang, Section 3.1, further teaches we obtain a set of unique and diverse answers (“stances”) using a GPT-3.5 judge. This constitutes the output of the first stage: semantically unique stances each with a corresponding frequency and aggregated mean confidence; Yang, Section 3.2 further teaches the diverse stances from Stage 1 are assigned to the general agents as deliberators).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford in view of Kumar and Padmanabhan, to further include the plurality of LLM agents stance generation, as taught by Yang, in order to demonstrate the effectiveness of collaborative calibration on generative QA tasks across various domains showing its potential in harnessing the rationalization of collectively calibrated confidence assessments and improving the reliability of model predictions. (Yang, Abstract and pg. 2, par. 2)
However, the combination does not distinctly disclose:
…initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state.
Nevertheless, Jumnongsaksub teaches …initiating a resolution protocol configured to revert the transaction by halting execution and removing any blockchain state changes from executing the transaction, restoring the blockchain to its prior state (Jumnongsaksub, pg. 3, teaches when the EVM detects a fatal error, it halts the current execution, reverts the global state, and marks the transaction as failed).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford in view of Kumar, Padmanabhan, and Yang, to further include the algorithm to detect smart contract methods with bad transaction behavior, as taught by Jumnongsaksub, in order to reduce the number of failed transactions on the Ethereum blockchain by helping users to avoid sending transactions that will result in failure. This will improve the transaction processing performance of the overall network since transactions that are likely to fail are prevented and most of the transactions selected by miners for validation are successful transactions. Furthermore, we can reduce the overall storage of the blockchain by storing fewer failed transactions. (Jumnongsaksub, pg. 3, par. 2 and pg. 4, par. 1)
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub, as applied to claims 1 and 12, and further in view of Johnson et al. (US 20210089887 A1, filed Mar. 27, 2020 and published Mar. 25, 2021)
Regarding claim 4, the combination of Shillingford in view of Kumar Padmanabhan, Yang, and Jumnongsaksub all of the limitations of claim 1, however, the combination does not distinctly disclose wherein the ML model is trained on large datasets from a plurality of sources.
Nevertheless, Johnson teaches wherein the ML model is trained on large datasets from a plurality of sources (Johnson, Paragraph [0084] teaches one aspect of the present technology is training machine-learning models to perform processing tasks. Training machine-learning models is typical performed using large datasets, and thus, training machine-learning models may include the gathering and use of data available from various sources.).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford in view of Kuman, Padmanabhan, Yang, and Jumnongsaksub, with the machine learning training techniques, as taught by Johnson, in order to overcome the shortcomings in the prior art by providing system and methods of machine learning training techniques that are approximately scale invariant, which significantly simplifies large-batch learning. (Johnson, Paragraph [0023])
Regarding claim 14, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 1, and the combination further teaches and at least a natural language used to specify the transaction (Shillingford, Paragraph [0015] teaches according to various embodiments, extraction of the terms may be performed using a machine learning model trained for a specific type of contract, for a wider range of general contracts, or for more generalized natural language.; Shillingford, Paragraph [0020] further teaches [0020] In some embodiments, the natural language processing system (or subsystem) may be created by fine-tuning an existing machine learning natural language processing model trained with a general English language dataset (or other target language). That is, the natural language processing system or subsystem configured to convert English language contract terms to chaincodes did not previously exist. However, utilizing “transfer learning,” existing natural language processing models trained with general or generic English language datasets can be trained with fine-tuned datasets with an emphasis on contract terms, legal terms, programming languages, scripts, distributed ledger languages and protocols, blockchain protocols, and/or other materials to support conversion of contract terms to chaincodes for execution on a blockchain or ledger-based platform.; Shillingford, Paragraph [0013] teaches A natural language processing system (which may be a subsystem of a smart contract generation system, as described below) may utilize a trained machine learning model, such as the generative pre-trained transformer 3 (GPT-3) [i.e., an LLM])..
However, the combination does not distinctly disclose wherein the LLM is trained on large datasets from a plurality of sources.
Nevertheless, Johnson teaches wherein the LLM is trained on large datasets from a plurality of sources (Johnson, Paragraph [0084] teaches one aspect of the present technology is training machine-learning models to perform processing tasks. Training machine-learning models is typical performed using large datasets, and thus, training machine-learning models may include the gathering and use of data available from various sources.).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub, with the machine learning training techniques, as taught by Johnson, in order to overcome the shortcomings in the prior art by providing system and methods of machine learning training techniques that are approximately scale invariant, which significantly simplifies large-batch learning. (Johnson, Paragraph [0023])
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub, as applied to claim 1, and further in view of Abbasi Moghaddam (US 20210089603 A1, hereinafter “Abbasi”, filed Sep. 20, 2019 and published Mar. 25, 2021)
Regarding claim 9, the combination of Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub teaches all of the limitations of claim 1, however, the combination does not distinctly disclose wherein a set of transactions are processed using a same version of the ML model.
Nevertheless, Abbasi teaches wherein a set of transactions are processed using a same version of the ML model (Abbasi, Paragraph [0051] teaches machine learning models 238 include a global version, a set of personalized versions, and a set of job-specific versions. The global version includes a single machine learning model that tracks the behavior or preferences of all candidates with respect to all jobs in data repository 134 [i.e., the single machine learning model being understood as a same version of the ML model, as claimed].)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to have modified the smart contract generation system and methods, as taught by Shillingford in view of Kumar, Padmanabhan, Yang, and Jumnongsaksub, with the single machine learning model employed for all jobs in a repository, as taught by Abbasi, given that training and/or execution of machine-learning models with large numbers of features and/or large datasets typically require more memory, computational resources, and time than those of machine-learning models with smaller numbers of features and/or smaller datasets. Consequently, machine learning and/or analytics may be facilitated by mechanisms for improving the creation, profiling, management, sharing, selection, and reuse of features and/or machine learning models. (Abbasi, Paragraphs [0004]-[0005])
Conclusion
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 BEATRIZ RAMIREZ BRAVO whose telephone number is 571-272-2156. The examiner can normally be reached Mon. - Fri. 7:30a.m.-5:00p.m..
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, USMAAN SAEED can be reached at 571-272-4046. 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.
/B.R.B./Examiner, Art Unit 2146
/USMAAN SAEED/Supervisory Patent Examiner, Art Unit 2146
Prosecution Insights