Claim Rejections - 35 USC § 102
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responding to application papers dated 6/7/2024.
Claims 1-20 are pending in the application.
The Information disclosure statement filed on 9/18/2025 and 9/13/2024 are considered.
Claim Objections
Claims 1, 4, 5, 14, 15 and 20 are objected to because of the following informalities: per claims 1 and 20, it appears that ‘an’ is missing before associated memory. Per claims 4 and 14, it appears that “has” needs to be “have.” Per claims 5 and 15, “is” needs to be “are.”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
Claims 1-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Per claims 1 and 11, it is unclear if the environment generates the content based on interaction with the models or the models generate the content. Interpretation: the models generate the content.
Claims 3 and 13 recite the limitation "the at least one language.” There is insufficient antecedent basis for this limitation in the claim. Interpretation: claims 3 and 13 depend on claims 2 and 12 respectively.
Per claims 2-10 and 12-19, these claims are rejected because they depend on claims 1 and 11 respectively.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Specifically, claims 1-20are directed to an abstract idea.
Per claim 1, the claim is directed to an idea of itself, mental processes that can be performed in the human mind, or by a human using a pen and paper. The steps of selecting, generating a DSL plan, and generating code can be pure mental process because a developer can select and generate the plan and code manually using a pen and paper through observation, evaluation, judgment, opinion, Under Prong 1.
Under Prong 2, the additional limitations, the processing circuitry and memory are recited at a high-level of generality to apply the mental steps, the steps of receiving a prompt and extracting an intent of the message are mere data gathering, extracting steps for the mental steps, the execution of code and outing the generated content are mere execution of code using a generic computing component which are insignificant extra solution activities. The trained models are not recited as active features as the environment is configured to interact with the models, therefore, the environment which can be a generic execution tool for code execution and outputting the content. Even if the models generate the content, they are mere tools used to output a result (content) at best. There are no recitations on how they are trained to generate the content. Therefore, using a generic learning algorithm(s) and computer components described at a high level of generality for applying or performing the abstract idea and insignificant extra solution activities do not indicate any integration of the abstract idea into a practical application. See MPEP see MPEP 2106.05(f) /2106.05(h). If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components or insignificant extra solution activities (e.g. processors, devices, program instructions, receiving), then it falls within the "Mental Processes" grouping of abstract ideas (2019 PEG step 2A, Prong 1: Abstract idea grouping? Yes, Mental Process). At most, the steps of receiving and extracting, executing and outputting are not found to include anything more than what is well-understood, routine, conventional activity in the field. In this case, it is noted that the claimed extra-solution of data gathering, outputting/updating/transmitting is acknowledged to be a well-understood, routine, conventional activity court recognized as WURC examples in MPEP 2106.05(d)(ll), for example, data gathering and retrieving, storing data, updating, transmitting, and displaying a result - Symantec, Versata Dev, Content extraction, Electric Power Group). Insignificant extra solution activities or mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Viewing the limitations individually and as a combination, the additional elements merely perform data gathering, outputting using generic computing components as tools without integrating the abstract idea into a practical application. For at least these reasons, claim 1 is not patent eligible.
Per claims 2-10, these claims are directed to the same idea itself as in claim 1, reciting details of the mental steps and data without adding any other additional element that is significantly more because the models are used as generic tools to provide the output from an input.
Per claims 11-20, these claims are directed to the same idea itself as in claims 1-9, reciting details of data and the mental steps without adding any other additional element that is significantly more. Therefore, the claims are rejected for the same reasons as in claims 1-9.
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.
Claims 1-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gandhi et al. (“Natural Language Commanding via Program Synthesis,” 2023, cited) in view of Janakiraman (US20260030144).
Per claim 1:
Gandhi discloses: A computing system comprising: processing circuitry and associated memory configured to: receive a prompt including a message as natural language input from an interaction interface; extract an intent of the message (page 1, user intent expressed as natural language; page 2, natural language user queries; page 4, Semantic Interpreter takes as input a natural language user utterance and relevant document context. … to generate a prompt conditioned on the user utterance and document context … This prompt is fed into an LLM to generate a program representation of the user utterance in the Office Domain Specific Language (ODSL … The ODSL interpreter parses the ODSL program into an Abstract Syntax Tree (AST) and performs analysis to validate the program and identify errors).
Gandhi does not explicitly teach selecting a domain-specific language (DSL) domain corresponding to the intent of the message. Janakiraman teaches selecting a domain-specific language (DSL) domain corresponding to the intent of the message (Janakiraman, see at least [0034] the test generation system generates domain-specific language from the intent query … as a whole or for each process or task that refers to a different domain; [0047] provides an intent query to the context engine 105 (e.g., which can translate the intent query into domain-specific language segments) and further provides the intent query to the large language model 118); [0078] where each of the steps refer to a different software environment context and/or each require different software actions. … generates a first domain-specific language segment for a “calendar application” (e.g., what meetings do I have tomorrow) and a second domain-specific language segment for “employee catalog application.” [0083] the test generation system 102 can generate a set of test codes 410 (e.g., three different test codes) for the first query subcomponent 406 that performs a function test to determine 1) whether an API of function code 408 correctly queries an employee application, 2) whether the function code 408 returns a current employee position, and 3) whether the function code 408 is syntactically and logically valid; [0102] a valid operation can include the function code that validly generates an output. For example, valid operations of the function code can be determined according to the domain specific language and the data source that the function code relates to; [0022], A validation test can include checks for certain types of errors (e.g., syntax errors and/or logic errors) as well as checks for hazardous code that is otherwise syntactically and logically sound to thus prevent malicious/unsafe test code and/or to prevent hallucinations in test code generated by the large language model). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Janakiraman’s DSL domain selection with Gandhi’s ODSL system to modify Gandhi’s system to combine the DSL domain selection as taught by Janakiraman, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to software development or machine learning. Combining Janakiraman’s functionality with that of Gandhi results in a system that allows domain selection. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to prevent malicious/unsafe code and/or to improve accuracy and solution space, decoding, security, error handling etc. in a large language model environment (Janakiraman, see at least [0034] the test generation system generates domain-specific language from the intent query … as a whole or for each process or task that refers to a different domain; [0047] provides an intent query to the context engine 105 (e.g., which can translate the intent query into domain-specific language segments) and further provides the intent query to the large language model 118); [0078] where each of the steps refer to a different software environment context and/or each require different software actions. … generates a first domain-specific language segment for a “calendar application” (e.g., what meetings do I have tomorrow) and a second domain-specific language segment for “employee catalog application.” [0083] the test generation system 102 can generate a set of test codes 410 (e.g., three different test codes) for the first query subcomponent 406 that performs a function test to determine 1) whether an API of function code 408 correctly queries an employee application, 2) whether the function code 408 returns a current employee position, and 3) whether the function code 408 is syntactically and logically valid; [0102] a valid operation can include the function code that validly generates an output. For example, valid operations of the function code can be determined according to the domain specific language and the data source that the function code relates to; [0022], A validation test can include checks for certain types of errors (e.g., syntax errors and/or logic errors) as well as checks for hazardous code that is otherwise syntactically and logically sound to thus prevent malicious/unsafe test code and/or to prevent hallucinations in test code generated by the large language model).
Gandhi in view of Janakiraman further teaches: generate a DSL plan encoded in a DSL based on the message and the selected DSL domain; generate code based on the message and the generated DSL plan (page 2, generate code based on the message and the generated DSL plan … transpile natural language user utterances to verifiable plans expressed as DSL programs … generate action plans in a DSL or API … the LLM may generate code; page 4, This prompt is fed into an LLM to generate a program representation of the user utterance in the Office Domain Specific Language; page 17. This analysis checks if an acceptable program is contained within a generated program, i.e., does the generated program do at least what the acceptable program performs note that the DSL programs expressing plans of the user utterances are generated DSL plans);
execute the code in a code execution environment to generate content corresponding to the message and the selected DSL domain, wherein the code execution environment is configured to interact with one or more trained generative models to generate the content; and output the generated content (page 1, Semantic Interpreter is a natural language-friendly AI system that leverages and enhances the power of large language models (LLMs) to execute user intent across application features; page 9, we limit ourselves to content generation and manipulation operations that can be reversed by the user with a simple undo operation; page 11, We then use the retrieved sample set Z to condition the LLM to synthesize the ODSL program output; page 15, creating presentations, adding new slides, inserting text content, modifying or rewriting existing content, inserting images, formatting entities in the document, etc. We do not include test cases for functionality that our ODSL exploration does not currently support; e.g., creating charts, file sharing, creating or resolving comment; page 8, the prompt we provide to the LLM … for program synthesis …the LLM response; Note that the Semantic Interpreter leverages an analysis-retrieval prompt engineering framework with LLMs to translate natural language user queries to ODSL programs that can be interpreted by Office applications to provide content).
Per claim 2:
Gandhi in view of Janakiraman further teaches: The computing system of claim 1, wherein the DSL is based on at least one language selected from the group consisting of: SQL (structured query language), HLSL/GLSL (High-Level Shading Language/Graphics Library Shader Language), Terraform language, MATLAB, R, machine learning languages, Ansible, and Cucumber (page 7, RESTAPIs, SQL, etc … design a language that is conducive to program synthesis via LLMs. We discuss some of our design choices to help make the ODSL LLM-friendly; page 3, PAL [15] and PoT [16] generate Python programs; page 6, Statements in ODSL are used to perform operations to interact with and create new entities in Office applications. Statements use syntax that loosely resembles function calls in Python (Python is used as a machine learning language).
Per claim 3:
Gandhi in view of Janakiraman further teaches: The computing system of claim 1, wherein a syntax and semantics of the at least one language are modified to include additional constructs to handle general-purpose programming tasks (page 2, the LLM may generate code that is semantically incorrect, have compile-time errors (syntax errors, unsupported statements/parameters, type errors, etc.) or result in runtime errors. To help reduce program synthesis errors, we create the Office Domain Specific Language (ODSL)); page 3, Synthesizing programs in general-purpose programming languages … we introduce a DSL that captures the functionality and semantics of Office commanding. Additionally, Semantic Interpreter includes a syntax validation and code correction procedure to ensure robustness of the synthesized program).
Per claim 4:
Gandhi in view of Janakiraman further teaches: The computing system of claim 1, wherein the one or more trained generative models has a generative pre-trained transformer architecture (page 2, LLMs typically have strict token limits for context length. For example, the GPT-3 and GPT-3.5 models from OpenAI have a token length limit of 4097 tokens and while more recent models like GPT-4).
Per claim 5:
Gandhi in view of Janakiraman further teaches: The computing system of claim 1, wherein the one or more trained generative models is a large language model (Gandhi, see at least abstract, We present Semantic Interpreter, a natural language-friendly AI system for productivity software such as Microsoft Office that leverages large language models (LLMs) to execute user intent across application features; page 2, LLMs are pretrained on large scale collections of code repositories).
Per claim 6:
Gandhi in view of Janakiraman further teaches: The computing system of claim 1, wherein the code execution environment is configured to interact with one or more agents to execute tasks in specialized domains to generate the content (page 6, page 15, user utterances that span only scenarios that our ODSL exploration for PowerPoint is able to express today: creating presentations; abstract, We therefore introduce the Office Domain Specific Language (ODSL), a concise, high-level language specialized for performing actions in and interacting with entities in Office applications. … We focus our discussion primarily on a research exploration for Microsoft PowerPoint; Note that the Office actions domain is a specialized domain).
Per claim 7:
Gandhi in view of Janakiraman further teaches: The computing system of claim 1, wherein the DSL domain is at least one selected from the group consisting of a book domain, a report domain, a website domain, a survey domain, a newsletter domain, a presentation domain, and a manual domain (Page 15, To help address the former, we created an evaluation set with 197 tests cases with user utterances that span only scenarios that our ODSL exploration for PowerPoint is able to express today: creating presentations, adding new slides, inserting text content, modifying or rewriting existing content, inserting images, formatting entities in the document, etc.; Note that the DSL domain is a presentation domain at least).
Per claim 10:
Gandhi further teaches wherein the DSL plan is generated using a trained generative model receiving the selected DSL domain as input (page 2, leveraging LLMs to transpile natural language user utterances to verifiable plans expressed as DSL programs … the LLM may generate code;
Per claims 11-17, they are the method versions of claims 1-7 and are rejected for the same reasons set forth in connection with the rejection of claims 1-7 above.
Per claim 20, it is the method version of claim 1 and is rejected for the same reasons set forth in connection with the rejection of claim 1 above.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gandhi in view of Janakiraman and Yu (CN 117348879).
Per claim 8:
Gandhi teaches wherein when the intent of the message is related to code development, the DSL plan is generated in a code development DSL, and the code is generated in a code development language (page 1, user intent expressed as natural language; page 2, natural language user queries; page 4, Semantic Interpreter takes as input a natural language user utterance and relevant document context. … to generate a prompt conditioned on the user utterance and document context … This prompt is fed into an LLM to generate a program representation of the user utterance in the Office Domain Specific Language (ODSL … The ODSL interpreter parses the ODSL program into an Abstract Syntax Tree (AST) and performs analysis to validate the program and identify errors; page 3, program synthesis in different domains. … generate Python programs which are offloaded to an external interpreter as the intermediate reasoning steps to solve problems expressed in natural language … Synthesizing programs in general-purpose programming languages).
Gandhi does not explicitly teach the code development is web development Yu teaches such web development (Yu, see at least fig. 5 and associated texts, a webpage generation workflow using domain specific languages to improve web development efficiency and saves development time). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Yu’s web development with Janakiraman’s DSL domain selection and Gandhi’s ODSL system to modify Gandhi’s system to combine the DSL domain for web development as taught by Yu, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to software development. Combining Yu’s functionality with that of Gandhi and Janakiraman results in a system that allows web development. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to to improve web development efficiency and saves development time (Yu, see at least fig. 5 and associated texts, a webpage generation workflow using domain specific languages to improve web development efficiency and saves development time).
Per claim 18, it is the method version of claim 8, and is rejected for the same reasons set forth in connection with the rejection of claim 8 above.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Gandhi in view of Janakiraman and Jones et al. (US20250148258, hereafter Jones).
Per claim 9:
Gandhi and Janakiraman do not explicitly teach wherein the DSL domain is selected using a trained generative model receiving the intent of the message as input. Jones teaches wherein the DSL domain is selected using a trained generative model receiving the intent of the message as input (Jones, see at least [0046] the control LLM 202 can be trained using one or more knowledge/data sources to generally understand each domain of the domain-specific LLMs 210, what questions may relate to each domain, what questions may be answered by (or may best be answered by) each of the domain-specific LLMs 210, any patterns that fit a question that any of the domain-specific LLMs 210 may answer, any information (e.g., issues, attributes, conditions, principles, parameters, problems, topics, concepts, etc.) that may relate to the domains (and/or associated questions) associated with the domain-specific LLMs 210, what model(s) from the domain-specific LLMs 210 may best understand a question and/or provide a most accurate and/or relevant response to the question, and/or otherwise how to intelligently select which model(s) from the domain-specific LLMs 210 to direct any given query to. …the formation testing model 224 to answer such query and direct the query to the resistivity model 212, the NMR model 214, the porosity model 216, and the formation testing model 224; [0093]). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Jones’ domain selection using a LLM with Janakiraman’s DSL domain selection and Gandhi’s ODSL system to modify Gandhi’s system to combine the DSL domain selection as taught by Janakiraman, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to software development or machine learning. Combining Jones’ functionality with that of Gandhi and Janakiraman results in a system that allows domain selection using a trained generative model. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to intelligently select a specific domain to provide more relevant and accurate output for the user query associated with a specific domain (Jones, see at least [0046] the control LLM 202 can be trained using one or more knowledge/data sources to generally understand each domain of the domain-specific LLMs 210, what questions may relate to each domain, what questions may be answered by (or may best be answered by) each of the domain-specific LLMs 210, any patterns that fit a question that any of the domain-specific LLMs 210 may answer, any information (e.g., issues, attributes, conditions, principles, parameters, problems, topics, concepts, etc.) that may relate to the domains (and/or associated questions) associated with the domain-specific LLMs 210, what model(s) from the domain-specific LLMs 210 may best understand a question and/or provide a most accurate and/or relevant response to the question, and/or otherwise how to intelligently select which model(s) from the domain-specific LLMs 210 to direct any given query to. …the formation testing model 224 to answer such query and direct the query to the resistivity model 212, the NMR model 214, the porosity model 216, and the formation testing model 224; [0093]).
Per claim 19, it is the method version of claim 9 and is rejected for the same reasons set forth in connection with the rejection of claim 9 above.
Examiner’s Note
The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20210182935 is related to utilizing a specialized domain-specific language model for generating cold-start;
US20250139447 is related to domain-specific prompt processing and answering involving plan generation and execution.
US20250165726 is related to integrating an LLM with organization-specific API(s) and/or tool(s) such that the LLM is able to act as a planner.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to INSUN KANG whose telephone number is (571)272-3724. The examiner can normally be reached M-TR 9am-5pm.
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, Chat Do can be reached at 571-272-3721. 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.
/INSUN KANG/ Primary Examiner, Art Unit 2193
Prosecution Insights