Notice of Pre-AIA or AIA Status
1. 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 Arguments
2. Applicant’s arguments with respect to claims 04/29/2026 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
3. 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.
4. Claims 1, 5, 7-9, 13, 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Fan et al. (US 2025/0078823), herein Fan, in view of Majmudar et al. (US 12,437,058), herein Majmudar.
Regarding Claim 1:
Fan discloses a method comprising:
receiving, by an artificial intelligence ("AI") assistant, a user query comprising one or more tasks (Fan: ¶35 discloses the large language model (LLM) orchestrator receiving user input data, generating a list of one or more tasks to perform an action responsive to the user input and selecting a current task);
determining one or more services based on the user query (Fan: ¶¶101-102 discloses retrieving one or more relevant APIs associated with the user input or current task by comparing the user input/current task with API descriptions to determine relevant APIs);
obtaining, for each of the one or more services, a plurality of examples, each example providing an example command suitable for execution by the respective service (Fan: ¶102 discloses API descriptions including one or more exemplars associated with use of the respective API, each exemplar including an example user input, a corresponding API call and an example API output. The corresponding API call is an example command suitable for execution by the respective API/service.);
generating one or more instructions based on the user query, the one or more services, and the one or more pluralities of examples (Fan: ¶100 discloses generating prompt data by combining the task data with relevant API data; ¶102 discloses that the relevant API data may include API descriptions containing exemplars, including an example user input, corresponding API call and example API output; ¶103 discloses that the prompt data is an instruction to the shortlister language model using the user input and relevant API data; ¶106 discloses that the exemplars contained in the API descriptions are included in the prompt data and used by the language model to generate the API call);
providing the one or more instructions to a trained large language model ("LLM") (¶¶27-28 and ¶100 and ¶103 discloses pre trained LLMs and providing the generated prompt data to shortlister language model 540);
receiving, from the LLM, one or more commands corresponding to the user query (Fan: ¶106 discloses the shortlister language model processing the prompt data to generate one or more API calls corresponding to requests responsive to the user input or current task, including required API-call parameters);
for each command of the one or more commands, issuing the respective command to a corresponding service of the one or more services (Fan: ¶¶107-108 discloses sending action plan data representing the generated requests to an action plan execution component, generating executable API calls and processing that action response data with the shortlister language model to generate responses);
generating a response to the user query based on results of the one or more commands (Fan: ¶¶115-116 discloses receiving action response data generated by the APIs in the response to the API calls and processing that action-response data with the shortlister language model to generate a natural language summary);
and outputting the response (Fan: ¶54 discloses generating a response or natural language summary responsive to the user input and outputting the selected response or summary to the user). Fan does not explicitly disclose:
after determining the one or more services;
Fan disclose selecting relevant APIs and obtaining API descriptions containing exemplars, but does not clearly require the claimed sequence in which the service is first determined and the service specific examples are thereafter obtained.
However, Majmudar discloses:
after determining the one or more services (Majmudar: Col 24 lines 37-57 discloses that if the API retrieval output indicates that a related API definition was identified the knowledge provider may cause the exemplar retrieval component to process to determine one or more exemplars related to the identified API definitions);
Fan and Majmudar are combinable because they are from the same field of endeavor. Both disclose systems and methods for processing natural-language user requests using LLMs, selecting APIs (services) relevant to the user request, using service specific exemplars to generate LLM prompts, generating API calls and executing the API calls to perform responsive actions. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to disclose modifying Fan so that its API associated exemplars are retrieved after identification of the relevant user request. Majmudar motivates this by teaching that exemplars are data “relevant for processing of the user input” and provide “example model outputs including an appropriate use of the API,” in Column 20 lines 18-24 therefore providing the language model with examples of appropriate API usage for performing the requested task.
Regarding Claim 5:
The proposed combination of Fan in view of Majmudar further discloses the method of claim 1, further comprising:
for each example, generating a relevancy based on the user query (Majmudar: Col 20 lines 15-21 discloses the one or more portions of data may be data that is determined relevant for processing the user input and that current user input is compared to example user input included in an exemplar);
and wherein obtaining, for each of the one or more services, the plurality of examples is based on the respective relevancies (Majmudar: Col 20 lines 21-25 the user input is determined relevant to one or more examples, exemplars, device states or contexts associated with the input).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Fan’s relevancy based API matching by retrieving exemplars corresponding to the identified APIs as taught by Majmudar because Majmudar teaches retrieving portions of data determined to be relevant for processing the user input, including exemplars corresponding to the relevant actions, thereby providing the LLM with examples of appropriate API usage relevant to the user request.
Regarding Claim 7:
The proposed combination of Fan in view of Majmudar further discloses the method of claim 1, wherein the issuing the respective command is performed by the AI assistant (Fan” ¶26 discloses system components including the LLM orchestrator component 130 and the action execution component 145; ¶107 discloses that the shortlister language model causes the generated requests to be executed by sending action plan data to the action plan execution component which generates executable API-call instructions; ¶108 discloses that the action plan execution component sends the resulting action data to the corresponding API provider, LLM agent, skill component or TTS component, therefore issuing the command from the assistant system to the corresponding service).
Regarding Claim 8:
The proposed combination of Fan, Majmudar and Reimers method of claim 1, wherein the issuing the respective command is performed by the trained LLM (Majmudar: Col 19 lines 1-13 discloses an inference engine implemented as a transformer based pre-trained LLM, Col 9 lines 30-34 further disclosing that the inference engine, action plan generator and action plan executor may be combined and implemented as the same component).
Fan and Majmudar are combinable because they are in the same field of endeavor, i.e., both disclose systems and methods for processing user requests using LLMs and APIs to perform responsive action. It would have been obvious to modify Fan to execute the function on by one of Fan’s LLM’s as taught by Majmudar to consolidate the generation and execution of actions within the LLM based processing system.
Regarding Claim 9:
Claim 9 has been analyzed with regard to claim 1 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
It is noted that Fan discloses a system comprising a non-transitory computer readable storage media at least at ¶ [181].
Regarding Claim 13:
Claim 13 has been analyzed with regard to claim 5 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
Regarding Claim 15:
Claim 15 has been analyzed with regard to claim 7 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
Regarding Claim 17:
Claim 17 has been analyzed with regard to claim 1 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
It is noted that Fan discloses a system comprising a non-transitory computer readable storage media at least at ¶ [181].
5. Claims 2-4, 6, 10-12, 14, 16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Fan in view of Majmudar, and further in view of Reimers et al. “Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks,” herein Reimers.
Regarding Claim 2:
The proposed combination of Fan in view of Majmudar further discloses the method of claim 1, further comprising:
generating, (Fan ¶102 discloses determining an encoded representation of the user input or current task for semantic comparison with API descriptions; the representations are compared using cosine similarity);
generating, (Fan ¶102 discloses an encoded representation of an API description, wherein the API description describes functions the API is configured to perform and other API information);
and wherein determining the one or more services is based on the one or more first embeddings and the one or more second embeddings (Fan ¶101 discloses retrieving one or more top-k relevant APIs associated with the user input or current; ¶102 discloses comparing the encoded representation of the user input/current task with the encoded representation of the API description using cosine similarity to determine whether the API is semantically similar to the user input/current task and including the API in the relevant API data when the semantic similarity value satisfies a threshold).
Fan does not disclose:
using a trained machine learning model;
using the trained machine learning model.
However, Reimers discloses:
using a trained machine learning model (Reimers: Fig. 1 discloses a SBERT architecture with tied weights);
using the trained machine learning model (Reimers: Fig. 1 discloses SBERT uses sentence A and sentence B, each are respectively processed by BERT networks to produce sentences embeddings u and v and explicitly state that the two BERT networks have tied weights).
Regarding Claim 3:
The proposed combination of Fan, Majmudar and Reimers further discloses the method of claim 2, further comprising:
determining, for each service, a confidence based on the one or more first embeddings and one or more second embeddings corresponding to the respective service (Fan: ¶102 discloses comparing the encoded representation of the user input with the encoded representation of each API description using cosine similarity to determine a semantic similarity value for the API; ¶124 discloses the API shortlister determining, for a particular API or API description a confidence value concerning whether that API description should be included in the relevant data);
and determining the one or more services based on the respective confidences and a confidence threshold (Fan: ¶102 discloses including an API in the relevant API data when its semantic similarity value meets or exceeds a threshold; ¶124 discloses determining a particular API description should be included when its confidence value meets or exceeds a particular threshold).
Fan, Majmudar and Reimers are combinable because they relate to processing natural language inputs using machine learning models and semantic similarity. It would have been obvious to use Reimers’ trained SBERT model to generate the embeddings used in the semantic similarity comparisons of Fan and Majmudar because Reimers teaches generating semantically meaningful sentence embedding using the same trained model and efficiently comparing those embeddings using cosine similarity.
Regarding Claim 4:
The proposed combination of Fan, Majmudar and Reimers further the method of claim 2, further comprising:
determining, for each service, a confidence based on the one or more first embeddings and one or more second embeddings corresponding to the respective service (Fan: ¶102 discloses comparing the encoded representation of the user input with the encoded representation of each API description using cosine similarity to determine a semantic similarity value for the API; ¶124 discloses the API shortlister determining, for a particular, for a particular API or API description a confidence value concerning whether that API description should be included in the relevant data);
and wherein obtaining, for each of the one or more services, the plurality of examples is based on the respective confidence for the respective service (Fan: ¶124 discloses using the respective API confidence to determine whether that API is selected for inclusion; Majmudar Col 24 lines 37-42 discloses that once a relevant API definition is identified the exemplar retrieval system exemplars obtained).
Regarding Claim 6:
The proposed combination of Fan, and Majmudar further discloses the method of claim 5, further comprising:
generating, (Fan ¶102 discloses determining an encoded representation of the user input or current task for semantic comparison with API descriptions; the representations are compared using cosine similarity);
generating,(Fan ¶102 discloses an encoded representation of an API description, wherein the API description describes functions the API is configured to perform and other API information);
and wherein generating the relevancy is based on at least a subset of the one or more first embeddings and the respective one or more second embeddings associated with the respective example (Majmudar: Col 23 lines 40-52 discloses the one or more exemplars may be included in the exemplar data based on them being semantically similar to the user input, Majmudar also discloses comparing using cosine similarity, the current user input to the example user input included in an exemplar to determine semantic similarity and including the exemplar when the example user input is determined similar).
Fan and Majmudar are combinable because they are in the same field of endeavor, i.e., both disclose systems and methods for processing user requests using LLMs and APIs to perform responsive action. It would have been obvious to modify Fan to retrieve exemplars corresponding to identified APIs as taught by Majmudar because Majmudar teaches that such exemplars are data relevant for processing the user input and provide examples of appropriate API use, therefore providing the LLM with relevant examples for generating API calls.
Fan and Majmudar do not explicitly disclose:
using a trained machine learning model;
using the trained machine learning model.
using a trained ML model (Reimers: Section 1 and Fig. 1 discloses using SBERT to input a sentence which the model processes to generate a first fixed size sentence embedding u, the networks have tired weights, such that the same trained model is used for the respective textual inputs);
using the trained ML model, one or more second embeddings based on the pluralities of examples (Reimers: Section 1 and Fig. 1 discloses a trained SBERT using a Siamese BERT architecture in which a first input sentence is processed to generate a first fixed size sentence embedding u);
Fan, Majmudar and Reimers are combinable because they relate to processing natural language inputs using machine learning models and semantic similarity. It would have been obvious to use Reimers’ trained SBERT model to generate the embeddings used in the semantic similarity comparisons of Fan and Majmudar because Reimers teaches generating semantically meaningful sentence embedding using the same trained model and efficiently comparing those embeddings using cosine similarity.
Regarding Claim 10:
Claim 10 has been analyzed with regard to claim 2 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
Regarding Claim 11:
Claim 1 has been analyzed with regard to claim 3 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
Regarding Claim 12:
Claim 12 has been analyzed with regard to claim 4 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
Regarding Claim 14:
Claim 14 has been analyzed with regard to claim 6 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
Regarding Claim 16:
Claim 16 has been analyzed with regard to claim 8 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
Regarding Claim 18:
Claim 18 has been analyzed with regard to claim 2 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
Regarding Claim 19:
Claim 19 has been analyzed with regard to claim 3 (see rejection above) and is rejected for the same reasons of obviousness set forth above
Regarding Claim 20:
Claim 20 has been analyzed with regard to claim 5 (see rejection above) and is rejected for the same reasons of obviousness set forth above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IAN SCOTT MCLEAN whose telephone number is (703)756-4599. The examiner can normally be reached "Monday - Friday 8:00-5:00 EST, off Every 2nd Friday".
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, Hai Phan can be reached at (571) 272-6338. 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.
/IAN SCOTT MCLEAN/Examiner, Art Unit 2654
/HAI PHAN/Supervisory Patent Examiner, Art Unit 2654
Prosecution Insights