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 .
Response to Amendment
The amendments filed 05/13/2026 have been accepted and considered in this office action. Claims 1, 9, and 17 have been amended. Claims 1-24 are pending.
Response to Arguments
Applicant’s arguments with respects to claims 1-24 have been considered but are moot in view of new grounds of rejection necessitated by the applicant’s amendments to the claims.
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 nonobviousness.
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-4, 8, 9-12, 16, 17-20, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (hereinafter Chen_1) (US 20240020116 A1) in view of Mishchenko et al. (hereinafter Mishchenko) (US 11922144 B1) (see attached copy for paragraph numbers) in further view of Liang et al (hereinafter Liang) (TaskMatrix.AI: Completing Tasks by Connecting Foundation Models with Millions of APIs).
Regarding claim 1, Chen _1 discloses:
A method, comprising:
operating a software application that utilizes an interface to receive commands from a user (Chen_1, Abstract, P[0005]: "receiving a docstring representing natural language text, wherein the docstring specifies a digital programming result," which reads on an interface receiving user intent to trigger logic generation (a command));
and
receiving the code generated from the LLM to implement the functionality to integrate with the third-party application (Chen_1, P[0016]: "generating, using a trained machine-learning model and based on the docstring, a computer code sample" and "identifying, based on the executing, a computer code sample configured to produce a particular candidate result," which reads on receiving the LLM-generated code and implementing it to fulfill the requested functionality)
Chen_1 does not explicitly disclose:
receiving a command during execution of the software application for functionality that is not programmed into the software application, wherein the functionality corresponds to integration of the software application with a third- party application;
determining actions that are automatable and are supported by the third- party application which are usable to implement the functionality;
generating a context for a large language model (LLM) to generate code corresponding to the functionality to integrate with the third-party application; and
where the functionality that is implemented was not previously programmed into the software application prior to the code generation and are based upon the actions that were determined to be automatable and supported by the third-party application.
However, Mishchenko discloses:
receiving a command during execution of the software application for functionality that is not programmed into the software application, wherein the functionality corresponds to integration of the software application with a third- party application (Mishchenko, Abstract: "receiving a first input at the natural language model user interface, determining the first input includes a request to integrate the particular external application programming interface (API) with the natural language model user interface", claim 3: "the particular external API is a third-party software API that provides access to data or functionality not natively available within a system associated with the natural language model user interface." (the first input reads on a command, and the request to integrate an external API reads on third-party application integration, and providing not natively available functionality reads on functionality not programmed into the software application and corresponding to third-party integration));
where the functionality that is implemented was not previously programmed into the software application prior to the code generation (Mishchenko, claim 3: "wherein the particular external API is a third-party software API that provides access to data or functionality not natively available within a system associated with the natural language model user interface." (not natively available functionality reads on functionality not previously programmed into the software application))
It would have been prima facie obvious to one of ordinary skill in the art before the earliest filing date of the claimed invention to have modified Chen_1 in view of Mishchenko. Doing so would have combined Chen_1’s generation of computer code form natural language programming intent (Chen_1, Abstract, P[0005]) with Mishchenko’s natural language model interface for integrating a third party/external API that provides functionality not natively available to the system (Mishchenko, claim 1, claim 3), thus, enabling a user’s natural language command to generate code for functionality corresponding to integration with a third party application.
The combination of Chen_1 and Mishchenko does not explicitly disclose:
determining actions that are automatable and are supported by the third- party application which are usable to implement the functionality
generating a context for a large language model (LLM) to generate code corresponding to the functionality to integrate with the third-party application
and are based upon the actions that were determined to be automatable and supported by the third-party application However, Liang discloses:
determining actions that are automatable and are supported by the third- party application which are usable to implement the functionality (Liang, Page 4: "The goal of API selector is to identify and select the most suitable APIs from API platform that fit the task requirement and solution outline", "The API selector can also leverage a module strategy to quickly locate relevant APIs." (selecting suitable APIs from the API platform reads on determining supported automatable actions usable to implement the requested functionality));
generating a context for a large language model (LLM) to generate code corresponding to the functionality to integrate with the third-party application (Liang, Page 2: "Multimodal Conversational Foundation Model (MCFM), which is responsible for communicating with users, understanding their goals and (multimodal) contexts, and generating executable codes based on APIs to accomplish specific tasks.", Liang, Page 3: "generates action codes using the recommended APIs, which will be further executed by calling APIs." ()); and
and are based upon the actions that were determined to be automatable and supported by the third-party application (Liang, Page 3: "The API selector chooses the most relevant APIs from the API platform according to the solution outline", "MCFM generates action codes using the recommended APIs", "generates the code of action using the selected APIs" (the generated action codes using selected/recommended APIs read on code based upon determined automatable/supported actions)).
It would have been prima facie obvious to one of ordinary skill in the art before the earliest filing date of the claimed invention to have modified Chen_1 in view of Mishchenko and in further view of Liang. Doing so would have combined Chen_1’s generation of computer code form natural language programming intent (Chen_1, Abstract, P[0005]) with Mishchenko’s natural language model interface for integrating a third party/external API that provides functionality not natively available to the system (Mishchenko, claim 1, claim 3), and with Liang’s API platform, API selector, and foundation model generation of action code using selected APIs (Liang, Pages 2-4), thus, enabling an LLM to use API documentation and selected supported API functions as context to generate code implementing requested third party application functionality
Regarding claim 2, the combination of Chen_1, Mishchenko, and Liang discloses the method of claim 1.
Liang further discloses:
wherein information used by the LLM to generate the code include at least one of LLM general knowledge, common code, or API documentation for the third-party application (Liang, Page 4: "the API platform specifies a unified API documentation schema… API Name… Parameter List… API Description… Usage Example… Composition Instructions…", "[MCFM] should be able to quickly learn how to use APIs from their documentation" (API documentation used by the MCFM/LLM to generate action code reads on API documentation for the third party application used by the LLM to generate code.)
Regarding claim 3, the combination of Chen_1, Mishchenko, and Liang discloses the method of claim 1.
Liang further discloses:
wherein English actions are mapped to function definitions in a programming language to provide information to the LLM to generate the code (Liang, Page 18: "you have access to a list of APIs to control PowerPoint with the following functions: create_slide(): This API is used to create a new slide. insert_text(text:str):This API is used to insert text into a textbox…", Page 19: "MCFM: Sure, here’s the code to generate slides for each company: create_slide(); select_title(); nsert_text("Microsoft");…" (English action descriptions are mapped to programming-language function definitions/calls and provided to the LLM to generate code))
Regarding claim 4, the combination of Chen_1, Mishchenko, and Liang discloses the method of claim 1.
Liang further discloses:
wherein natural language processing is performed to identify the functionality corresponds to integration with a third-party application (Liang, Page 3: "extract specific tasks from user instructions and propose reasonable solution outlines (as shown in Figure 1) that can help select the most relevant APIs for code generation.", Page 4: "The goal of API selector is to identify and select the most suitable APIs from API platform that fit the task requirement and solution outline" (processing natural language user instructions to extract tasks and select relevant APIs reads on NLP identifying functionality corresponding to third party/API integration)).
Regarding claim 8, the combination of Chen_1, Mishchenko, and Liang discloses the method of claim 1.
Chen_1 further discloses:
wherein the code is generated during a processing run by a user (Chen_1, P[0016]: "causing each of the one or more computer code samples to be executed" and "identifying, based on the executing, at least one of the computer code samples," which reads on a dynamic process where code is generated, executed, and identified in real-time during a user's active session).
Regarding claim 9, claim 9 recites the computer system corresponding to the method presented in claim 1 and is rejected under the same grounds stated above. Additionally, the combination further discloses or makes obvious:
A system, comprising:
a processor (Chen_1, P[0016]);
a memory for holding programmable code (Chen_1, P[0016]); and
wherein the programmable code includes instructions for (Chen_1, P[0016])
Regarding claim 10, claim 10 recites the system corresponding to the method presented in claim 2 and is rejected under the same grounds as above.
Regarding claim 11, claim 10 recites the system corresponding to the method presented in claim 3 and is rejected under the same grounds as above.
Regarding claim 12, claim 10 recites the system corresponding to the method presented in claim 4 and is rejected under the same grounds as above.
Regarding claim 16, claim 10 recites the system corresponding to the method presented in claim 8 and is rejected under the same grounds as above.
Regarding claim 17, claim 17 recites the computer program product corresponding to the method presented in claim 1 and is rejected under the same grounds stated above. Additionally, the combination further discloses or makes obvious:
A computer program product embodied on a computer readable medium, the computer readable medium having stored thereon a sequence of instructions which, when executed by a processor, performs (Chen_1, P[0133]):
Regarding claim 18, claim 18 recites the computer program product corresponding to the method presented in claim 2 and is rejected under the same grounds as above.
Regarding claim 19, claim 19 recites the computer program product corresponding to the method presented in claim 3 and is rejected under the same grounds as above.
Regarding claim 20, claim 20 recites the computer program product corresponding to the method presented in claim 4 and is rejected under the same grounds as above.
Regarding claim 24, claim 24 recites the computer program product corresponding to the method presented in claim 8 and is rejected under the same grounds as above.
Claims 5-7, 13-15, and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (hereinafter Chen_1) (US 20240020116 A1) in view of Mishchenko et al. (hereinafter Mishchenko) (US 11922144 B1) (see attached copy for paragraph numbers) in further view of Liang et al (hereinafter Liang) (TaskMatrix.AI: Completing Tasks by Connecting Foundation Models with Millions of APIs) and Chen et al. (hereinafter Chen_2) (US 20240020096 A1).
Regarding claim 5, the combination of Chen_1, Mishchenko, and Liang discloses the method of claim 1.
The combination of Chen_1, Mishchenko, and Liang does not explicitly disclose:
wherein an iterative process is performed to generate the code, whereby a plurality of cycles of code generation followed by error handling is performed to correct an error identified for the generated code.
However, Chen_2 discloses:
wherein an iterative process is performed to generate the code, whereby a plurality of cycles of code generation followed by error handling is performed to correct an error identified for the generated code (Chen_2, P[0140]: "model refinement engine 860 may transmit the received output to featurization engine 820 or ML modeling engine 830 in one or more iterative cycles" and "output validation engine 850 (e.g., configured to apply validation data to machine learning model output)," and P[0078]: "automated testing (e.g., generating test cases and test code, which may help developers ensure that their code is functioning correctly and catch bugs from the outset)," which reads on a system performing iterative cycles where code is generated, validated via testing to "catch bugs," and refined to correct identified errors).
It would have been prima facie obvious to one of ordinary skill in the art before the earliest filing date of the claimed invention to have modified Chen_1 in view of Mishchenko and in further view of Liang and Chen_2. Doing so would have combined Chen_1’s generation of computer code form natural language programming intent (Chen_1, Abstract, P[0005]) with Mishchenko’s natural language model interface for integrating a third party/external API that provides functionality not natively available to the system (Mishchenko, claim 1, claim 3), Liang’s API platform, API selector, and foundation model generation of action code using selected APIs (Liang, Pages 2-4), and Chen_2’s verification, testing, and model improvement process for generated code samples (Chen_2, P[0062]-P[0070]) thus, enabling generated third party/API integration code to be iteratively verified, corrected, and improved for future processing.
Regarding claim 6, the combination of Chen_1, Mishchenko, Liang, and Chen_2 discloses the method of claim 5.
Chen_2 further discloses:
wherein a revised context is provided to the LLM in an iterative manner to generate revised code to correct for the error (Chen_2, P[0140]: "infer a change to input or model parameters to cause a particular model output or type of model output," and P[0078]: "automatically generating code changes based on code review comments, which may save time and improve the efficiency of the code review process," which reads on providing a revised context (specifically code review feedback or an inferred change to the model's input) to the generator in an iterative manner to correct errors).
Regarding claim 7, the combination of Chen_1, Mishchenko, Liang, and Chen_2 discloses the method of claim 5.
Chen_2 further discloses:
wherein a learned procedure for error resolution is stored for a future processing (Chen_2, P[0140]: "Outcome metrics database 880 may be configured to store output from one or more models" and "configured to correlate output, detect trends in output data, and/or infer a change to input or model parameters to cause a particular model output," which reads on storing model outputs and learned trends/correlations in a persistent database to serve as a learned procedure for informing future generation cycles).
Regarding claim 13, claim 13 recites the system corresponding to the method presented in claim 5 and is rejected under the same grounds as above.
Regarding claim 14, claim 14 recites the system corresponding to the method presented in claim 6 and is rejected under the same grounds as above.
Regarding claim 15, claim 15 recites the system corresponding to the method presented in claim 7 and is rejected under the same grounds as above.
Regarding claim 21, claim 21 recites the computer program product corresponding to the method presented in claim 5 and is rejected under the same grounds as above.
Regarding claim 22, claim 22 recites the computer program product corresponding to the method presented in claim 6 and is rejected under the same grounds as above.
Regarding claim 23, claim 23 recites the computer program product corresponding to the method presented in claim 7 and is rejected under the same grounds as above.
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 SHASHIDHAR S MANOHARAN whose telephone number is (571)272-6772. The examiner can normally be reached M-F 8:00-4:00.
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, Andrew Flanders can be reached at 571-272-7516. 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.
/SHASHIDHAR SHANKAR MANOHARAN/ Examiner, Art Unit 2655
/ANDREW C FLANDERS/ Supervisory Patent Examiner, Art Unit 2655
Prosecution Insights