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 .
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 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.
Claims 1, 4, 9 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Papayiannis (US-20250104693-A1) in further view of Canberk (US-20250299668-A1),Dewynter (US-20250315629-A1), and Radu (US-20240403560-A1).
With respect to claims, 1, 9 and 15 Papayiannis teaches (Claim 1) A method for API connectors, comprising; (Claim 9) A non-transitory computer-readable medium storing a program for API connectors, which when executed by a computer, configures the computer to ([0206] Computer instructions for operating each device (410/420/425) and its various components may be executed by the respective device's controller(s)/processor(s) (1004/1104), using the memory (1006/1106) as temporary “working” storage at runtime. A device's computer instructions may be stored in a non-transitory manner in non-volatile memory (1006/1106), storage (1008/1108), or an external device(s). Alternatively, some or all of the executable instructions may be embedded in hardware or firmware on the respective device in addition to or instead of software.); (Claim 15). A system for API connectors, comprising
receiving from a user account a first API request formatted for a source system, the first API request comprising an intent (Papayiannis ¶ [0103] For example, the API shortlister component 620 may compare one or more APIs included in the index storage 630 to the user input or the current task to determine one or more APIs (top-k) that corresponds to the user input or the current task (e.g., APIs that are semantically similar to the user input [intent] or the current task, APIs that are capable of performing the current task, etc.). … representation of an API description [natural language description] for the API to determine whether the API is semantically similar to the user input or the current task ¶ [0115] For further example, the API provider component 650 may include a search component, which may be configured to query a storage (e.g., a database, repository, knowledge base, etc.) for information usable for generating a response to a user input. For example, if the action data 647a-n represents a request for information of “Who won the game between [Team 1 Name] and [Team 2 Name],” then the search component may query the storage (or other sources, such as the Internet), to retrieve the information “[Team 1 Name] won the game between [Team 1 Name] and [Team 2 Name].”, and Par.0117:” In some embodiments, the API provider component 650 may include a domain service [skill] component, which may be configured for interacting with one or more services [skills] defined by particular users, such as developers, specialists, or the like (e.g., to receive information, such as responses or annotations, to cause an action.”, ¶[0117]:” In some embodiments, the API provider component 650 may include a domain service component, which may be configured for interacting with one or more services [skills] defined by particular users, such as developers, specialists, or the like (e.g., to receive information, such as responses or annotations, to cause an action);
using the first API request, selecting from a storage a first defined action corresponding to the intent, the first defined action comprising a first plurality of parameters that characterize the first defined action and a first natural language description of the first defined action (Papayiannis ¶[0103]The API shortlister component 620 may use retrieval-based approaches to retrieve the one or more relevant APIs from the index storage 630, which may store various information associated with multiple APIs such as API descriptions [natural language description of the first defined action], API arguments (e.g., parameter inputs/outputs), identifiers for components (e.g., such as personalized context component 465, skill component(s) 654, LLM agent component(s) 652, TTS component 380) that provides the API, etc. For example, the API shortlister component 620 may compare one or more APIs included in the index storage 630 to the user input or the current task to determine one or more APIs (top-k) that corresponds to the user input [intent] or the current task (e.g., APIs that are semantically similar to the user input or the current task, APIs that are capable of performing the current task, etc.).);
generating a first prompt from the first plurality of parameters and the first natural language description ([0101] As further shown in FIG. 6, the task data 437 is received at the shortlister prompt generation component 610. The shortlister prompt generation component 610 processes the task data 437 to generate prompt data 615 representing a prompt for input to the shortlister language model 640. In some embodiments, such prompt data 615 may be generated based on combining the task data 437 (e.g., the user input data 102, the context data 105, the selected task, remaining tasks, potential responses associated with one or more previous tasks, etc.) and relevant API data 635 representing one or more APIs associated with the user input data 102 and/or the current task.);
providing, to a first large language model (LLM), the first prompt ([0121] In some embodiments, the LLM orchestrator component 430 may further include a memory storage (not illustrated) which may store various information associated with the processing performed (e.g., user input data 102, the prompt data 515, the context data 105, the personalized context data 467, the model output data 525, prompt data 535, the task data 437, the relevant API data 635, the prompt data 615, the action plan data 442, the action response data 458a-n, the potential response data 443a-n, etc.) during one or more previous iterations of processing by the LLM orchestrator component 430 for the user input data 102. As such, after the LLM shortlister component 440 generates the potential response data 443a-n, the LLM orchestrator component 430 may send the abovementioned data to the memory storage. In some embodiments, the above-mentioned data may be sent to the memory storage as it is generated by the system 100.);
receiving, from the first LLM, a response to the first prompt, the response comprising [[a structured description of the intent]] ([0121] In some embodiments, the LLM orchestrator component 430 may further include a memory storage (not illustrated) which may store various information associated with the processing performed (e.g., user input data 102, the prompt data 515, the context data 105, the personalized context data 467, the model output data 525, prompt data 535, the task data 437, the relevant API data 635, the prompt data 615, the action plan data 442, the action response data 458a-n, the potential response data 443a-n, etc. [structured description of intent]) during one or more previous iterations of processing by the LLM orchestrator component 430 for the user input data 102. As such, after the LLM shortlister component 440 generates the potential response data 443a-n, the LLM orchestrator component 430 may send the abovementioned data to the memory storage. In some embodiments, the above-mentioned data may be sent to the memory storage as it is generated by the system 100.);
Papayiannis does not explicitly disclose however Canberk teaches structured description of the intent (Canberk ¶[006] the LLM is instructed to formulate output that specifically indicates the intent of the user, and is formatted in a structured manner, for example, as a JavaScript Object Notation (JSON) object.)
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify API system of Papayiannis to include the structured description of Canberk in order to standardize output format ([0113], Canberk);
Papayiannis and Canberk do not explicitly disclose however Dewynter teaches using the structured description of the intent, selecting from the storage a second defined action, the second defined action comprising a second plurality of parameters that characterize the second defined action and a second natural language description of the second defined action (¶Dewynter[0058] Application 120 also tasks generative AI model 150 with suggesting an action or intent for modifying selected content 142 in view of the feedback, ¶[0060]The user may also review and edit rewrite 147 in graphical pane 146 before accepting it into document 141. In some cases, the user may submit a natural language request to modify rewrite 147, causing application 120 to submit a third prompt to generative AI model 150 including rewrite 147 and the user's natural language request [rewrite and request are parameters].);
generating a second prompt comprising the second plurality of parameters and the second natural language description (¶[0060]The user may also review and edit rewrite 147 in graphical pane 146 before accepting it into document 141. In some cases, the user may submit a natural language request to modify rewrite 147, causing application 120 to submit a third prompt to generative AI model 150 including rewrite 147 and the user's natural language request [rewrite and request are parameters]);
providing, to a second LLM, the second prompt (¶[0060]The user may also review and edit rewrite 147 in graphical pane 146 before accepting it into document 141. In some cases, the user may submit a natural language request to modify rewrite 147, causing application 120 to submit a third prompt to generative AI model 150 including rewrite 147 and the user's natural language request [rewrite and request are parameters]);
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify API system of Papayiannis in view of the structured description of Canberk to include the second plurality of parameters of Dewynter in order to improve user experience and reduce latency in processing ([0036], Dewynter);
Papayiannis and Prasad and Dewynter do not explicitly disclose however Radu teaches receiving, from the second LLM, a response to the second prompt, the response comprising a second API request formatted for a destination system ([0021] In some embodiments, the approach provides the tokenized LLM output (or encoded LLM output) and an instruction to a second LLM (or back to the same LLM). The approach (e.g., one of the LLMs) then performs the instruction based on the tokenized LLM output. In some embodiments, the tokenized LLM output includes a tokenized API call, );
providing the second API request to the destination system (Radu ¶[0034]The tokenized LLM output t240 includes a tokenized API call, where the tokenized API call includes one or more of the tokens. For example, tokenized LLM output 240 may contain the tokenized API call “USE TOOL: delete_file Token-asdfg,” which is detokenized by de-scrubber 150 [destination system] to “USE TOOL: delete_file malicious.exe,” which then causes the file by the specified name to be deleted.);
receiving, from the destination system, a response to the second API request (¶Claim 14. The system of claim 8, wherein the tokenized LLM output comprises a tokenized API call, and wherein the processing device, responsive to executing the instructions, further causes the system to: produce a detokenized API call by replacing the at least one of the one or more tokens in the tokenized API call with at least one of the one or more data elements; execute the detokenized API call to produce the database response; and provide the detokenized LLM output to a user interface.) ; and
providing the response to the second API request to the user account (¶ Claim 14. The system of claim 8, wherein the tokenized LLM output comprises a tokenized API call, and wherein the processing device, responsive to executing the instructions, further causes the system to: produce a detokenized API call by replacing the at least one of the one or more tokens in the tokenized API call with at least one of the one or more data elements; execute the detokenized API call to produce the database response; and provide the detokenized LLM output to a user interface.).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify API system of Papayiannis in view of the structured description of Canberk in view of the second plurality of parameters of Dewynter to include destination system of Radu in order to reduce adversarial manipulation of LLMs ([0022], Radu);
With respect to claim 4, Canberk further teaches wherein the structured description of the intent is stored in the storage as a JavaScript Object Notation (JSON) data structure (Canberk ¶ [006] the LLM is instructed to formulate output that specifically indicates the intent of the user, and is formatted in a structured manner, for example, as a JavaScript Object Notation (JSON) object.)
Claims 2, 10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Papayiannis, Canberk Dewynter, Radu in further view of Ferenczi (US-20250097054-A1).
With respect to claims 2, 10 and 16 none of Papayiannis, Canberk Dewynter and Radu explicitly disclose however Ferenczi teaches using the structured description of the intent, retrieving from a secure storage an authentication credential associated with the destination system, wherein the second prompt further comprises the authentication credential (Ferenczi ¶[0010] In contrast to other approaches involving time-consuming entry of responses reliant on human memory, the approaches herein use generative LLMs to conduct automated authentication based at least in part on a shared body of text which is known to both parties. In various examples, an authentication session can be established between a verification agent of an entity (e.g., verifier, inquirer, etc.) and a personalized authentication agent of the user (e.g., credential holder, responder, etc.). In various examples, the verification agent and the authentication agent can use LLMs trained on the same private text corpus to conduct authentication through a series of prompts and responses).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify API system of Papayiannis in view of the structured description of Canberk in view of the second plurality of parameters of Dewynter in view of destination system of Radu to include authentication of Ferenczi in order to reduce the likelihood that a malicious actor could predict the prompts ([0011], Ferenczi);
Claims 3, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Papayiannis, Canberk Dewynter, Radu in further view of Shachar (US- 20240372876 -A1).
With respect to claims 3, 11 and 17 none of Papayiannis, Canberk Dewynter and Radu explicitly disclose however Shachar teaches wherein the second LLM is the first LLM (Shachar ¶[0007] Optionally, the first LLM, the second LLM, and the third LLM are the same LLM.).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify API system of Papayiannis in view of the structured description of Canberk in view of the second plurality of parameters of Dewynter in view of destination system of Radu to include LLMs of Shachar in order to increase efficiency ([0004], Shachar);
Claims 5, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Papayiannis, Canberk Dewynter, Radu in further view of Nichol (US-12141539-B1).
With respect to claims 5, 12 and 18 none of Papayiannis, Canberk Dewynter and Radu explicitly disclose however Nichol teaches wherein the user account selects the first defined action from a directory (Nicol ¶Col8 ll15-20 The second type of action is a custom action. The name of a custom action starts with action_. The example uses a custom action, action_check_sufficient_funds, to check whether the user has enough money to make the transfer, and then add logic to the flow to handle both cases. The custom action is defined in the file actions.py).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify API system of Papayiannis in view of the structured description of Canberk in view of the second plurality of parameters of Dewynter in view of destination system of Radu to include file of Nichol in order to reduce latency (Col2ll21-28, Nichol);
Claims 6, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Papayiannis, Canberk Dewynter, Radu in further view of Kumar (US-20250110618-A1).
With respect to claims 6, 13 and 19 none of Papayiannis, Canberk Dewynter and Radu explicitly disclose however Kumar teaches wherein the first API request comprises a first plurality of endpoints, the method further comprising identifying at least one endpoint from the first API request, wherein selecting the first defined action is based on the at least one identified endpoint (Kumar¶[0153] In other cases, the output processor/gateway can be configured to determine whether an output of the generative engine service 116 is an API request that should be directed to a particular endpoint. Upon identifying an intended or specified endpoint, the output processor can transmit the output, as an API request to that endpoint. The gateway may receive a response to the API request which in some examples, may be directed to yet another system (e.g., a notification that an object has been modified successfully in one system may be transmitted to another system)).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify API system of Papayiannis in view of the structured description of Canberk in view of the second plurality of parameters of Dewynter in view of destination system of Radu to include endpoints of Kumar in order to minimize time and resource requirements ([0003], Kumar);
Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Papayiannis, Canberk, Dewynter, Radu and Kumar in further view of Korlam (US-20230079904-A1) and Olsen (US-20200285528-A1)
With respect to claims 7, 14 and 20 none of Papayiannis, Canberk Dewynter, Radu and Kumar explicitly disclose however Korlam teaches wherein the second API request comprises a second plurality of endpoints (Korlam ¶ [0041]Example of the metadata include the mapping of the API endpoint to a SDK endpoint to replace, the intent of a SDK's endpoint);
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify API system of Papayiannis in view of the structured description of Canberk in view of the second plurality of parameters of Dewynter in view of destination system of Radu in view of endpoints of Kumar to include secondary endpoints of Korlam in order to minimize time and resource requirements.
None of Papayiannis, Canberk Dewynter, Radu, Kumar and Korlam explicitly disclose however Olsen teaches and electing the second defined action comprises using the structured description of the intent to generate a mapping between the first plurality of endpoints to the second plurality of endpoints (Olsen ¶ [0106] Once the endpoint mapping matching the natural language input is identified the chatbot may execute an action according to the endpoint mapping, declared by the documentation configuration reference of the API of the second plurality of APIs, matching the natural language input).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify API system of Papayiannis in view of the structured description of Canberk in view of the second plurality of parameters of Dewynter in view of destination system of Radu in view of endpoints of Kumar in view of endpoints of Korlam to include mappings of Olsen of in order to minimize time and resource requirements.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Papayiannis, Canberk, Dewynter, Radu, Kumar, Korlam, Olsen and in further view of Sarkar (US-20150095474-A1)
With respect to claim 8, none of Papayiannis, Canberk Dewynter, Radu, Kumar, Korlam and Olsen explicitly disclose however Sarkar teaches wherein the at least one endpoint is a Uniform Resource Locator (URL) (Sarkar ¶ [0052] In another embodiment, an apparatus may identify a capability type for the facet; modify the capability type with values related to the facet to form a specific capability type; and add the capability type to a capability set type, wherein the capability set type is associated with the facet. In yet a further embodiment, an apparatus may create a URL endpoint uniquely identifying the endpoint, wherein the URL endpoint comprises an action request).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify API system of Papayiannis in view of the structured description of Canberk in view of the second plurality of parameters of Dewynter in view of destination system of Radu in view of endpoints of Kumar in view of endpoints of Korlam in view of mappings of Olsen to include URL of Sarkar in order to uniquely address endpoint (Sarkar, [0041]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ATHAR N PASHA whose telephone number is (408)918-7675. The examiner can normally be reached on Monday-Thursday Alternate Fridays, 7:30-4:30 PT.
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, Daniel Washburn can be reached on (571)272-5551. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ATHAR N PASHA/Primary Examiner, Art Unit 2657
Prosecution Insights