Prosecution Insights
Last updated: October 02, 2026
Application No. 18/793,460

SMART CONTRACT CREATION AND MANAGEMENT USING GENERATIVE ARTIFICIAL INTELLIGENCE WITH MODEL MERGING

Non-Final OA §103§DOUBLEPATENT
Filed
Aug 02, 2024
Priority
Mar 28, 2023 — provisional 63/492,770 +5 more
Examiner
BROPHY, MATTHEW J
Art Unit
Tech Center
Assignee
U.S. Bancorp
OA Round
1 (Non-Final)
68%
Grant Probability
Favorable
1-2
OA Rounds
1y 5m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allowance Rate
428 granted / 625 resolved
+8.5% vs TC avg
Strong +34% interview lift
Without
With
+34.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 7m
Avg Prosecution
16 currently pending
Career history
643
Total Applications
across all art units

Statute-Specific Performance

§101
11.3%
-28.7% vs TC avg
§103
61.1%
+21.1% vs TC avg
§102
14.0%
-26.0% vs TC avg
§112
8.0%
-32.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 625 resolved cases

Office Action

§103 §DOUBLEPATENT
DETAILED ACTION The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This office action is in response to the application filed August 2, 2024. Claims 1-20 are pending. The application claims benefit to prior filed applications 18/493,619, 18/493,572 18/493,487 and provisional applications 63/492,770, 63/492,771 and 63/492,773. Upon review of the claimed subject matter and the prior filings, the pending claims as currently construction are not entitled to any of the earlier filing dates and are examined herein as entitled to the August 2, 2024 filing date. Specifically, each of the independent claims recites limitations claiming merging of multiple models not supported by the prior filed application. (e.g. claim 1 recites “the generative artificial intelligence model being a merged model constructed from a base model and a secondary model, the base model being a generative pre-trained transformer (GPT) model and the secondary model being trained using training data directed to at least one attribute of the smart contract code;”) Double Patenting The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. Claims 1,2,6,7 and 16 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1,1,6,7, and 1 respectively of copending Application No. 18/493572 (reference application) in view of “Gutta” (US PG Pub 2023/0038529) in view of “Madisetti” (US Patent 12,001,462) This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented. The pending claims are obvious in view of the pending claims as aligned below, and further in view of “Gutta” (US PG Pub 2023/0038529) in view of “Madisetti” (US Patent 12,001,462) This application Application 18/493572 1. A method comprising: receiving text input describing a desired operation of a smart contract; based, at least in part, on the text input, utilizing a generative artificial intelligence model to generate smart contract code, the generative artificial intelligence model being a merged model constructed from a base model and a secondary model, the base model being a generative pre-trained transformer (GPT) model and the secondary model being trained using training data directed to at least one attribute of the smart contract code; validating the smart contract code; and deploying the smart contract code on a blockchain in response to successfully validating the smart contract code. 2. The method of claim 1, wherein processing the text input with the large language model includes outputting synthetic data for validating the smart contract code, and wherein validating the smart contract code includes using the synthetic data to simulate transactions with the smart contract code. 6. The method of claim 1, wherein the secondary model is trained on a corpus of optimized and validated example smart contract code. 7. The method of claim 1, further comprising processing the text input at a first model to output a smart contract logic description that is provided to the generative artificial intelligence model. 16. A computer-implemented method of method of generating and validating a smart contract, the method comprising:receiving text input describing a desired operation of a smart contract; based, at least in part, on the text input, utilizing a generative artificial intelligence model to generate smart contract code, the generative artificial intelligence model being a merged model constructed from a base model and a secondary model, the base model being a generative pre-trained transformer (GPT) model and the secondary model being trained using training data directed to at least one attribute of the smart contract code; validating execution of the smart contract code using a set of synthetic smart contract test data, including monitoring execution of the smart contract code via an agent configured to receive transaction data generated by the smart contract code; and deploying the smart contract code on a blockchain in response to successfully validating the smart contract code. 1. (Previously Presented) A method for generating and validating a smart contract, the method comprising: receiving text input describing a desired operation of a smart contract; … processing the smart contract logic description with a generative artificial intelligence model to generate smart contract code; validating the smart contract code using the synthetic data to simulate transactions with the smart contract; and deploying the smart contract code on a blockchain upon successful validation of the smart contract code. Claim 1… validating the smart contract code using the synthetic data to simulate transactions with the smart contract; 6. (Original) The method of claim 1, wherein the generative artificial intelligence model is trained on a corpus of optimized and validated example smart contract code. [1.]… processing the text input with a language model to generate a smart contract logic description and a textual description of a scenario for validating the smart contract, 1. (Previously Presented) A method for generating and validating a smart contract, the method comprising: receiving text input describing a desired operation of a smart contract; … processing the smart contract logic description with a generative artificial intelligence model to generate smart contract code; validating the smart contract code using the synthetic data to simulate transactions with the smart contract; and deploying the smart contract code on a blockchain upon successful validation of the smart contract code. Regarding Claim 1, The claims do not teach but Gutta teaches: and the secondary model being trained using training data directed to at least one attribute of the smart contract code; (Gutta ¶¶22-24,35 teach training of a model based on smart contract code) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of previous claims and Gutta as each is directed to machine learning systems and Gutta recognized “By converting some or all of a natural language document or associated unstructured tables into a smart contract, some embodiments may increase the transparency and interpretability of the natural language document. Furthermore, by generating program code directly from a natural language document, errors between document creation and enforcement of the rules written in the document may be reduced.” (¶19). The claims do not teach but Madisetti teaches: the generative artificial intelligence model being a merged model constructed from a base model and a secondary model, the base model being a generative pre-trained transformer (GPT) model (Madisetti e.g. Fig. 4, 310, Col. 3, Ln 10-27 and Col. 6, Ln 22-35 teaches mergin of multiple llm models in a merging/fusing process; Madisetti e.g. Col. 5, Ln 53-62 teaches the merged LLMs include GPT models) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of previous claims and Madisetti as each is directed to machine learning systems and Madiseeti recognized merging “a machine learning technique which improves the stability and accuracy of machine learning models.” (Col. 6, Ln 22-35). Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 1, 7, 10 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Gutta” (US PG Pub 2023/0038529) in view of “Madisetti” (US Patent 12,001,462) Regarding Claim 1, Gutta teaches: 1. A method comprising: receiving text input describing a desired operation of a smart contract; (Gutta 404, Fig. 4, ¶¶17-18,52-58 teaches receiving text input of various types for creation of smart contracts) based, at least in part, on the text input, utilizing a generative artificial intelligence model to generate smart contract code, (Gutta 430, Fig. 4, ¶¶17-18,65 teaches generation of smart contract code using a ML model to generate code) …and the secondary model being trained using training data directed to at least one attribute of the smart contract code; (Gutta ¶¶22-24,35 teach training of a model based on smart contract code) validating the smart contract code; (Gutta ¶¶17,34, 66, 250, Fig, 2 teach validation of the smart contract code before deployment ) and deploying the smart contract code on a blockchain in response to successfully validating the smart contract code. (Gutta ¶¶17,35, 66, 260, Fig, 2 teach deployment of the smart contract to the blockchain after validation). Gutta does not teach, but Madisetti teaches: the generative artificial intelligence model being a merged model constructed from a base model and a secondary model, the base model being a generative pre-trained transformer (GPT) model (Madisetti e.g. Fig. 4, 310, Col. 3, Ln 10-27 and Col. 6, Ln 22-35 teaches mergin of multiple llm models in a merging/fusing process; Madisetti e.g. Col. 5, Ln 53-62 teaches the merged LLMs include GPT models) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Madisetti as each is directed to machine learning systems and Madiseeti recognized merging “a machine learning technique which improves the stability and accuracy of machine learning models.” (Col. 6, Ln 22-35). Regarding Claim 7, Gutta teaches: 7. The method of claim 1, further comprising processing the text input at a first model to output a smart contract logic description that is provided to the generative artificial intelligence model. (Gutta ¶¶17-18 teaches generative a structure section from a deep neural network and subsequent providing them to subsequent models to generate code) Regarding Claim 10, Gutta teaches: 10. The method of claim 1, … the second GPT model being trained using the training data that includes documentation relevant to the application of the smart contract code. (Gutta ¶¶22-24,35 teach training of a model based on smart contract code) and Madisetti further teaches: wherein the secondary model comprises a second generative pre-trained transformer (GPT) model having fewer parameters than the base model, (Madisetti Fig. 6 Col. 6, Ln 54-72 teaches creating smaller specialized models with fewer parameters which maybe then be using in fusing with base models, such as in Fig. 7; Madisetti e.g. Col. 5, Ln 53-62 teaches the merged LLMs include GPT models) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Madisetti as each is directed to machine learning systems and Madiseeti recognized merging “a machine learning technique which improves the stability and accuracy of machine learning models.” (Col. 6, Ln 22-35). Regarding Claim 12, Gutta teaches: 12. The method of claim 1, wherein the secondary model further includes a GPT model trained to build communications protocols between the smart contract code and external systems within the blockchain and external to the blockchain. (Gutta ¶¶17-23, 65 teaches using a model for building smart contracts run on the block chain including on chain and off chain communication) Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Gutta” (US PG Pub 2023/0038529) in view of “Madisetti” (US Patent 12,001,462) as applied above and further in view of “Hron” (US Patent 11,909,858). Regarding Claim 2, Gutta does not further teach, but Hron teaches: 2. The method of claim 1, wherein processing the text input with the large language model includes outputting synthetic data for validating the smart contract code, . (Col. 5, Ln 1 to Col. 6, Ln 50, 308-318, Fig. 3, teaches using the cross-compiler 308, which employees trained language model(s), fig. 3 to generate dummy variable for validating the smart contract in a sandboxed environment) and wherein validating the smart contract code includes using the synthetic data to simulate transactions with the smart contract code (Hron Col. 6, 41-50 teaches validating the smart contract using dummy values before transporting it downstream) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Hron as each is directed to smart contract generation systems and Hron recognized “An incorrectly implemented smart contract can be exploited by malicious actors or even have unintended consequences due to errors in the underlying code.” (Col. 1, Ln 50-55). Claim(s) 3, 4, 5, 14-17, 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Gutta” (US PG Pub 2023/0038529) in view of “Madisetti” (US Patent 12,001,462) and “Hron” (US Patent 11,909,858) as applied above and further in view of “Padmanabhan” (US PG Pub 2019/0236598). Regarding Claim 3, Gutta does not further teach, but Padmanabhan teaches: 3. The method of claim 2, further comprising monitoring operation of the smart contract with one or more agents, the one or more agents receiving transaction data generated by the smart contract code. (Padmanabhan ¶¶126-127,300-303,455-456,474 teach use a ML-based agents for monitoring and analyzing of smart contracts on a blockchain) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Padmanabhan as each is directed to smart contract generation systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment.” (¶9). Regarding Claim 4, Gutta does not further teach, but Padmanabhan teaches: 4. The method of claim 3, wherein the one or more agents is generated by a second generative artificial intelligence model. (Padmanabhan ¶¶126-127,300-303,455-456,474 teach use a ML-based agents for monitoring and analyzing of smart contracts on a blockchain) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Padmanabhan as each is directed to smart contract generation systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment.” (¶9). Regarding Claim 5, Gutta further teaches: 5. The method of claim 4, …and the further model being a fine-tuned model trained using smart contract transaction data. (Gutta ¶¶17-23, 65 teaches using a model for building smart contracts run on the block chain including on chain and off chain communication) Gutta does not teach, but Madisetti teaches: wherein the second generative artificial intelligence model comprises a second merged model constructed from at least a base model and a further model, the base model being a generative pre-trained transformer (GPT) model (Madisetti e.g. Fig. 4, 310, Col. 3, Ln 10-27 and Col. 6, Ln 22-35 teaches mergin of multiple llm models in a merging/fusing process; Madisetti e.g. Col. 5, Ln 53-62 teaches the merged LLMs include GPT models) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Madisetti as each is directed to machine learning systems and Madiseeti recognized merging “a machine learning technique which improves the stability and accuracy of machine learning models.” (Col. 6, Ln 22-35). Regarding Claim 14, Gutta does not teach, but Hron teaches: 14. The method of claim 1, wherein validating the smart contract code comprises:generating a set of synthetic smart contract test data at a validation model; (Col. 5, Ln 1 to Col. 6, Ln 50, 308-318, Fig. 3, teaches using the cross-compiler 308, which employees trained language model(s), fig. 3 to generate dummy variable for validating the smart contract in a sandboxed environment) executing the smart contract code on the synthetic smart contract test data; (Hron Col. 6, 41-50 teaches validating the smart contract using dummy values before transporting it downstream) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Hron as each is directed to smart contract generation systems and Hron recognized “An incorrectly implemented smart contract can be exploited by malicious actors or even have unintended consequences due to errors in the underlying code.” (Col. 1, Ln 50-55). Gutta further does not teach, but Padmanabhan teaches: and monitoring execution of the smart contract code via an agent configured to receive transaction data generated by the smart contract code. (Padmanabhan ¶¶126-127,300-303,455-456,474 teach use a ML-based agents for monitoring and analyzing of smart contracts on a blockchain) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Padmanabhan as each is directed to smart contract generation systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment.” (¶9). 15. The method of claim 14, wherein the agent (Padmanabhan ¶¶126-127,300-303,455-456,474 teach use a ML-based agents for monitoring and analyzing of smart contracts on a blockchain) [here, while the model’s used in Padmanabhan agent’s are not described as generative, but machine-learning based, it would have been obvious to one of ordinary skill to combine with the generative AI LLMs of Madisetti described below] In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Padmanabhan as each is directed to smart contract generation systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment.” (¶9). Gutta further does not teach but Madisetti teaches: comprises a generative AI model, and wherein at least one of the validation model or the agent comprises a merged model. (Madisetti e.g. Fig. 4, 310, Col. 3, Ln 10-27, Col. 6, Ln 22-35 teaches the use of generative LLMs and teaches mergin of multiple llm models in a merging/fusing process; Madisetti e.g. Col. 5, Ln 53-62 teaches the merged LLMs include GPT models) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Madisetti as each is directed to machine learning systems and Madiseeti recognized merging “a machine learning technique which improves the stability and accuracy of machine learning models.” (Col. 6, Ln 22-35). Regarding Claim 16, Gutta teaches: 16. A computer-implemented method of method of generating and validating a smart contract, the method comprising: receiving text input describing a desired operation of a smart contract; (Gutta 404, Fig. 4, ¶¶17-18,52-58 teaches receiving text input of various types for creation of smart contracts) based, at least in part, on the text input, utilizing a generative artificial intelligence model to generate smart contract code, (Gutta 430, Fig. 4, ¶¶17-18,65 teaches generation of smart contract code using a ML model to generate code) …and the secondary model being trained using training data directed to at least one attribute of the smart contract code; (Gutta ¶¶22-24,35 teach training of a model based on smart contract code) validating execution of the smart contract code (Gutta ¶¶17,34, 66, 250, Fig, 2 teach validation of the smart contract code before deployment ) and deploying the smart contract code on a blockchain in response to successfully validating the smart contract code. (Gutta ¶¶17,35, 66, 260, Fig, 2 teach deployment of the smart contract to the blockchain after validation). Gutta does not teach, but Madisetti teaches: the generative artificial intelligence model being a merged model constructed from a base model and a secondary model, the base model being a generative pre-trained transformer (GPT) model (Madisetti e.g. Fig. 4, 310, Col. 3, Ln 10-27 and Col. 6, Ln 22-35 teaches mergin of multiple llm models in a merging/fusing process; Madisetti e.g. Col. 5, Ln 53-62 teaches the merged LLMs include GPT models) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Madisetti as each is directed to machine learning systems and Madiseeti recognized merging “a machine learning technique which improves the stability and accuracy of machine learning models.” (Col. 6, Ln 22-35). Gutta does not further teach, but Hron teaches: using a set of synthetic smart contract test data (Col. 5, Ln 1 to Col. 6, Ln 50, 308-318, Fig. 3, teaches using the cross-compiler 308, which employees trained language model(s), fig. 3 to generate dummy variable for validating the smart contract in a sandboxed environment) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Hron as each is directed to smart contract generation systems and Hron recognized “An incorrectly implemented smart contract can be exploited by malicious actors or even have unintended consequences due to errors in the underlying code.” (Col. 1, Ln 50-55). Gutta does not further teach, but Padmanabhan teaches: including monitoring execution of the smart contract code via an agent configured to receive transaction data generated by the smart contract code; (Padmanabhan ¶¶126-127,300-303,455-456,474 teach use a ML-based agents for monitoring and analyzing of smart contracts on a blockchain) at least one of the one or more agents being generated (Padmanabhan ¶¶126-127,300-303,455-456,474 teach use a ML-based agents for monitoring and analyzing of smart contracts on a blockchain) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Padmanabhan as each is directed to smart contract generation systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment.” Regarding Claim 17, Gutta further teaches: 17. The computer-implemented method of claim 16, further comprising…and the secondary model being a fine-tuned model trained using smart contract transaction data. (Gutta ¶¶22-24,35 teach training of a model based on smart contract code) Gutta further does not teach, but Padmanabhan teaches: monitoring operation of the smart contract code after deployment via one or more agents, the one or more agents receiving transaction data generated by the smart contract code, (Padmanabhan ¶¶126-127,300-303,455-456,474 teach use a ML-based agents for monitoring and analyzing of smart contracts on a blockchain) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Padmanabhan as each is directed to smart contract generation systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment.” Gutta does not teach, but Madisetti teaches: by a merged model including a base model and a secondary model, the base model being a generative pre-trained transformer (GPT) model (Madisetti e.g. Fig. 4, 310, Col. 3, Ln 10-27 and Col. 6, Ln 22-35 teaches mergin of multiple llm models in a merging/fusing process; Madisetti e.g. Col. 5, Ln 53-62 teaches the merged LLMs include GPT models) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Madisetti as each is directed to machine learning systems and Madiseeti recognized merging “a machine learning technique which improves the stability and accuracy of machine learning models.” (Col. 6, Ln 22-35). Regarding Claim 19, Gutta teaches: 19. A smart contract generation and validation system comprising: a smart contract code generation model executable to generate smart contract code, the smart contract code generation model (Gutta 430, Fig. 4, ¶¶17-18,65 teaches generation of smart contract code using a ML model to generate code) and the secondary model being trained using training data directed to at least one attribute of the smart contract code; (Gutta ¶¶17,35, 66, 260, Fig, 2 teach deployment of the smart contract to the blockchain after validation) Gutta does not teach, but Madisetti teaches: being a merged model constructed from a base model and a secondary model, the base model being a generative pre-trained transformer (GPT) model (Madisetti e.g. Fig. 4, 310, Col. 3, Ln 10-27 and Col. 6, Ln 22-35 teaches mergin of multiple llm models in a merging/fusing process; Madisetti e.g. Col. 5, Ln 53-62 teaches the merged LLMs include GPT models) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Madisetti as each is directed to machine learning systems and Madiseeti recognized merging “a machine learning technique which improves the stability and accuracy of machine learning models.” (Col. 6, Ln 22-35). Gutta does not further teach, but Hron teaches: a verification model executable to receive transaction data output from the smart contract code in response to execution of the smart contract code using a set of synthetic smart contract test data; (Hron Col. 6, 41-50 teaches validating the smart contract using dummy values before transporting it downstream) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Hron as each is directed to smart contract generation systems and Hron recognized “An incorrectly implemented smart contract can be exploited by malicious actors or even have unintended consequences due to errors in the underlying code.” (Col. 1, Ln 50-55). Gutta does not further teach, but Padmanabhan teaches: and an agent that is executable to monitor transaction data output from the smart contract code after deployment onto a blockchain. (Padmanabhan ¶¶126-127,300-303,455-456,474 teach use a ML-based agents for monitoring and analyzing of smart contracts on a blockchain) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Padmanabhan as each is directed to smart contract generation systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment.” (¶9). Regarding Claim 20, Gutta does not further teach, but Padmanabhan teaches: 20. The smart contract generation and validation system of claim 19, wherein the agent provides the transaction data to a …model to analyze the transaction data. (Padmanabhan ¶¶126-127,300-303,455-456,474 teach use a ML-based agents for monitoring and analyzing of smart contracts on a blockchain) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Padmanabhan as each is directed to smart contract generation systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment.” (¶9). Gutta further does not teach but Madsetti teaches: generative pre-trained transformer (GPT) (Madisetti e.g. Col. 5, Ln 53-62 teaches the merged LLMs include GPT models) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Madisetti as each is directed to machine learning systems and Madiseeti recognized merging “a machine learning technique which improves the stability and accuracy of machine learning models.” (Col. 6, Ln 22-35). Claim(s) 6 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Gutta” (US PG Pub 2023/0038529) in view of “Madisetti” (US Patent 12,001,462) as applied above and further in view of “Storhaug” (Storhaug, André, Jingyue Li, and Tianyuan Hu. "Efficient avoidance of vulnerabilities in auto-completed smart contract code using vulnerability-constrained decoding." 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE). IEEE, 2023.) Regarding Claim 6, Gutta does not further teach, but Storhaug teaches: 6. The method of claim 1, wherein the secondary model is trained on a corpus of optimized and validated example smart contract code.(Storhaug Sections II and III describe training a mode with verified smart contract code which has been optimized for uniqueness and identified vulnerabilities). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Storhaug as each is directed to machine learning systems and Storhaug’s technique created an “approach could efficiently and effectively avoid vulnerabilities in the auto-completed code.: (Abstract). Regarding Claim 11, Gutta does not further teach, but Storhaug teaches: 11. The method of claim 1, wherein the base model comprises a GPT model trained to output smart contract code and the secondary model comprises a GPT model trained to generate risk scenarios associated with the smart contract code, the risk scenarios being integrable into the smart contract code by .(Storhaug Abstract, Sections II and III teach a trained model for identifying and avoiding vulnerabilities in smart contract code) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Storhaug as each is directed to machine learning systems and Storhaug’s technique created an “approach could efficiently and effectively avoid vulnerabilities in the auto-completed code.: (Abstract). and Mandsetti further teaches: merging the base model and the secondary model. (Madisetti e.g. Fig. 4, 310, Col. 3, Ln 10-27 and Col. 6, Ln 22-35 teaches mergin of multiple llm models in a merging/fusing process) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Madisetti as each is directed to machine learning systems and Madiseeti recognized merging “a machine learning technique which improves the stability and accuracy of machine learning models.” (Col. 6, Ln 22-35). Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Gutta” (US PG Pub 2023/0038529) in view of “Madisetti” (US Patent 12,001,462) as applied above and further in view of “Padmanabhan” (US PG Pub 2019/0236598). Regarding Claim 8, Gutta does not teach, but Padmanabhan teaches: 8. The method of claim 1, wherein the one or more agents are deployed to the blockchain to monitor the smart contract code and generate one or more reports regarding operation of the smart contract code. (Padmanabhan ¶¶126-127,300-303,455-456,474 teach use a ML-based agents for monitoring and analyzing of smart contracts on a blockchain) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Padmanabhan as each is directed to smart contract generation systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment.” (¶9). Claim(s) 9 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Gutta” (US PG Pub 2023/0038529) in view of “Madisetti” (US Patent 12,001,462) as applied above and further in view of “Worstman” (Wortsman, Mitchell, et al. "Model soups: averaging weights of multiple fine-tuned models improves accuracy without increasing inference time." International conference on machine learning. Pmlr, 2022.) Regarding Claim 9, Gutta does not teach, but Worstman teaches: 9. The method of claim 1, wherein the merged model forming the generative artificial intelligence model comprises a weighted average ensemble. (See Worstman Abstract – teaching a Model Soups system that uses weight averaging for model merging). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Worstman as each is directed to systems using machine learning systems and Worstman recognized “that averaging the weights of multiple models fine tuned with different hyperparameter configura tions often improves accuracy and robustness.” (Abstract). Regarding Claim 13, Gutta does not teach, but Worstman teaches: 13. The method of claim 1, wherein the base model comprises a pretrained GPT model, and wherein the secondary model includes a plurality of secondary models; ( ) and wherein model merging is performed on the plurality of secondary models to form a merged secondary model, followed by merging the base model with the merged secondary model. (See Worstman Abstract – teaching a Model Soups system that uses weight averaging for model merging, Further Section 1 teaches Greedy Soups wherein models are sequentially merged). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Worstman as each is directed to systems using machine learning systems and Worstman recognized “that averaging the weights of multiple models fine tuned with different hyperparameter configura tions often improves accuracy and robustness.” (Abstract). Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Gutta” (US PG Pub 2023/0038529) in view of “Madisetti” (US Patent 12,001,462) and “Hron” (US Patent 11,909,858) and “Padmanabhan” (US PG Pub 2019/0236598) as applied above and further in view of “Naramore” (US PG Pub 2021/0327216). Regarding Claim 18, Gutta does not further teach but Naramore teaches: 18. The computer implemented method of claim 17, wherein deploying the smart contract code comprises deploying the smart contract code onto a layer 2 blockchain, and wherein at least after deployment, the smart contract code is immutable. (Naramore e.g. ¶32 describes a system for generating and deploying smart contracts to the layer 1 and layer 2 blockchain, where it has an immutable structure for the processing of blockchain transaction). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date to combine the teachings of Gutta and Naramore as each is directed to systems for deploying smart contracts on a blockchain and Naramore recognized “ Layer 2 integration with the GCE allows a smart contract to determine which data needs to be permanently and immutably recorded to the blockchain versus which data is transitory, or of lesser importance, and may be recorded into associated applications or databases.” (¶32). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The prior art cited in the attached PTO-892 form includes prior art relevant to the application’s disclosures related to smart contract generation and AI model merging. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4:30pm. 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, Wei Zhen can be reached at 571-272-3708. 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. MJB 9/17/2026 /MATTHEW J BROPHY/Primary Examiner, Art Unit 2191
Read full office action

Prosecution Timeline

Aug 02, 2024
Application Filed
Sep 21, 2026
Non-Final Rejection mailed — §103, §DOUBLEPATENT (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12724596
EXCLUDING FIRMWARE UPGRADE TRAFFIC FROM CUSTOMER PROVISIONED BANDWIDTH
3y 4m to grant Granted Sep 01, 2026
Patent 12710945
CROSS-PLATFORM CODE CONVERSION METHOD AND DEVICE
3y 10m to grant Granted Aug 18, 2026
Patent 12699551
ELECTRONIC APPARATUS EQUIPPED WITH A UI DEVELOPMENT TOOL CAPABLE OF RECOMMENDING A TEMPLATE FOR A UI COMPONENT BASED ON THE CHARACTERISTICS OF THE UI TO BE DEVELOPED AND THE OPERATING METHOD THEREOF
3y 0m to grant Granted Aug 04, 2026
Patent 12681698
PLATFORM FOR INTEGRATING BACK-END DATA ANALYSIS TOOLS USING SCHEMA
2y 5m to grant Granted Jul 14, 2026
Patent 12664076
TEST COVERAGE OPTIMIZING MECHANISM BASED ON METRIC EVALUATION SYSTEM
3y 5m to grant Granted Jun 23, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
68%
Grant Probability
99%
With Interview (+34.3%)
3y 7m (~1y 5m remaining)
Median Time to Grant
Low
PTA Risk
Based on 625 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month