DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed on 06/13/2025.
Claims 21-40 are pending.
Claim Objections
Claim 38 is objected to because of the following informalities: “wherein set of executable APIs comprises” should read “wherein the set of executable APIs comprises”. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 29-32 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 29 recite(s) the limitation(s): “the next sequenced API selected by a large language model by comparing embeddings generated by a small language model representing the natural language request in the payload request to embeddings representing the functionality of each API in the plurality of relevant APIs;”. However, upon review of the initial application filing, proper support in the written description for this limitation was not found. The instant specification states: “The network system 120, using the orchestration module 122, applies 520 a small language model to the payload request to determine a set of candidate APIs in the API catalog 130. To do so, the small language model parses the natural language of the payload request into a set of embeddings in vector space. The small language model uses the embeddings of the payload request to search for APIs that provide the requested functionality, in effect comparing the embeddings representing the payload request to the embeddings representing the API in vector space” in paragraph 80, and the specification further states “The network system 120, using the orchestration module 122, applies 530 a large language model to the payload request and the set of candidate APIs. To do so, the large language model parses the natural language of the payload request and the candidate APIs (and, in some cases, their associated meta data) into a set of embeddings. The large language model uses the embeddings to determine the intent and context of the natural language request, and uses the intent and context to determine which of the candidate APIs is the most relevant for providing the requested functionality” in paragraph 82. While, a small language model is used to generate embeddings, there is no recitation of these embeddings generated by the small language model being used by a large language model to compare with embeddings representing functionality of APIs. Thus, there is a lack of support in the initial filing for this limitation of claim 29. If applicant disagrees that there is support within the written description, please provide citation to where the support can be found within the specification.
Claims 30-32 depend, directly or indirectly, from rejected claims and do not resolve the deficiencies thereof and are therefore rejected for at least the same reasons.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 29-32, 36, and 39 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.
Claims 32 and 36 recite the limitation “executing the sequenced API executes the sequenced on API on the additional network system”. It is unclear what is meant by this limitation. Further, there is insufficient antecedent basis for “the sequenced API” and “the sequenced on API” in the claims or in claims 29 and 33, from which the claims depend. For the sake of compact prosecution, Examiner will interpret this limitation to mean “executing a sequenced API the sequenced API
Further, claim 36 recites the limitation “one or more of the sequenced APIs” in line 1. There is insufficient antecedent basis for this limitation in the claim, or in claim 33 from which the claim depends. For the sake of compact prosecution, Examiner will interpret this limitation to mean “one or more API of the ordered sequence of
Claims 29 and 39 recite the limitations “executing the next sequenced API”, “executing an additional API (from the set of executable) / (of the plurality of relevant) APIs as the next sequenced API”. It appears as though “the next sequenced API” is referring to different APIs in a chain; however, it is unclear whether there are multiple next sequenced APIs claimed or if these recitations in the claim are directed to the same next sequenced API. For the sake of compact prosecution, Examiner will interpret the first recitation to mean “executing a sequenced API of the API chain”.
Claims 30-32 depend, directly or indirectly, from rejected claims and do not resolve the deficiencies thereof and are therefore rejected for at least the same reasons.
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 25, 27, and 28 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 25, 27, and 28 are directed to a method and fall within the statutory category of process. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claim 25: The limitations of “applying, at the network system, a first model to the natural language request to determine a set of candidate APIs from an API catalog, the determination comprising: generating, with the first model, data representations that map natural language in the request to functionality of APIs in the catalog,”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a natural language request and an API catalog and, based on these observations, can mentally determine a set of candidate APIs by mentally generating data representations that map natural language in the request to functionality of APIs in the catalog. This may also be done with pencil and paper. Further, the limitations of “and selecting, based on the representations, candidate APIs, wherein the selected APIs have at least a threshold level of similarity between the natural language in the request and functionality of APIs in the API catalog; ”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a data representations and, based on these observations, can mentally select candidate APIs that have at least a threshold level of similarity between the natural language in the request and functionality of APIs in the API catalog. This may also be done with pencil and paper. Further, the limitations of “applying, at the network system, a second model to the natural language request and the candidate APIs to determine a selected API that performs the requested functionality represented in the natural language request, the second model interpreting the natural language request to select a most relevant candidate API from the set of candidate APIs as the selected API;”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a natural language request and candidate APIs and, based on these observations, can mentally determine a selected API that performs the requested functionality represented in the natural language request by mentally interpreting the natural language request to select a most relevant candidate API from the set of candidate APIs. This may also be done with pencil and paper.
Therefore, Yes, claim 25 recites a judicial exception.
Step 2A Prong 2:
Claim 25: The judicial exception is not integrated into a practical application. In particular, the claims recite additional element recitations of “receiving, at a network system, a natural language request for a payload from a client device;” and “and transmitting the generated response to the client device”, which are merely recitations of data reception and transmission which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “applying, at the network system, a first model to the natural language request to determine…”, “applying, at the network system, a second model to the natural language request and the candidate APIs to determine…”, and “executing the selected API to generate a response including the requested functionality;”, which are merely recitations of generically using a computer as a tool to implement the abstract idea (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
After having evaluated the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claim 25 not only recites a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claim 25: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than insignificant extra solution activity and generic computing components which do not amount to significantly more than the abstract idea. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network… iii. Electronic recordkeeping… iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)].
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claim 25 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 27, the claim recites additional element recitations of “wherein the selected API is stored on an additional network system”, which are merely recitations of data storage which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the claim recites additional element recitations of “and executing the selected API comprises executing the selected API on the additional network system”, which are merely recitations of generically using a computer as a tool to implement the abstract idea (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claim 27, does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 27, also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 27 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 28, the claim recites additional element recitations of “wherein the selected API is stored on an additional network system and executing the selected API comprises: providing the selected API from the additional network system to the network system;”, which are merely recitations of data storage and transmission which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the claim recites additional element recitations of “and executing the selected API on the network system”, which are merely recitations of generically using a computer as a tool to implement the abstract idea (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claim 28, does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 28, also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 28 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Therefore, Claims 25, 27, and 28 do not recite patent eligible subject matter under U.S.C. §101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 21-23, 26, 33, 34, and 36 is/are rejected under 35 U.S.C. 103 as being unpatentable over Devaux et al. US 2024/0370505 A1 (hereafter Devaux) in view of Papayiannis et al. US 2025/0104693 A1 (hereafter Papayiannis) in view of Teng et al. US 2025/0131190 A1 (hereafter Teng).
With regard to claim 21, Devaux teaches:
A method for generating a payload response for a requested functionality in a system environment, the method comprising: “Block 312 comprises defining structured response formats for unstructured queries. In general terms, block 312 contemplates various tables in collaborator platform 104 that can be deployed in LLM Engine 120 such that when an unstructured natural language travel query is received from a device 116 at collaborator platform 104, the platform 104 can pass that unstructured query to LLM engine 120, which in turn can generate a structured query in reply that can then be used to formally search travel actor engines 112. The results from the travel actor engines 112 can then be returned to the originating device 116” [Devaux ¶ 109]. “FIG. 28 is an illustrative representation showcasing the application of a formal API description in the generation of a chain of thought” [Devaux ¶ 74, fig. 28].
receiving, at a network system, a payload request from a client device, the payload request comprising a natural language request for the requested functionality; “FIG. 28 illustrates the LLM's capacity to engage in a contextually adaptive dialogue, employing its reasoning capabilities to sequence API calls and data processing tasks in response to a user's natural language query” [Devaux ¶ 310, fig. 28]. “The one or more travel contexts from block 308 include tables that provide contextual shifts for LLM engine 120, that situate LLM engine 120 in the context of a travel assistant and establish how the LLM engine 120 is to manage and respond to natural language travel queries received at various client devices 116 on behalf of users 124, as those queries are received by collaborator platform 104 and passed along to LLM engine 120” [Devaux ¶ 103].
applying, at the network system, a small language model to the payload request to determine a set of candidate APIs from a catalog based on embeddings generated by the small language model that map(ping) the natural language in the payload request to the functionality of the APIs in the catalog; “Block 2508 comprises determining at least one parameter from a request intention within the conversational session” [Devaux ¶ 251]. “Block 2512 comprises determining a meta-description based on the parameters. This involves synthesizing a concise overview of the data related to the identified parameters, which serves to contextualize and streamline the selection process in subsequent steps” [Devaux ¶ 257]. “Block 2516 comprises selecting, based on the at least one parameter and the meta-description, a plurality of nodes representing sources within a full domain of sources. These sources may include, but are not limited to, a function call via an application programming interface (API), a database, and a large language model. The meta-description acts as a set of criteria that enables the system to understand and categorize the information required from different sources. The meta-description guides the actual search engine server (e.g. Travel management engine 122b) in identifying which nodes (e.g. Travel actor engines 112) are relevant for the search query, and what kind of information to retrieve from them” [Devaux ¶ 258-259]. “Identification of Data Sources: The meta-description can outline the types of data needed to satisfy the user's query. Based on the criteria specified in the meta-description, the search engine server determines which APIs (candidate APIs), databases, or language models have the potential to provide the required information. Matching Criteria with Capabilities: The search engine server compares the criteria from the meta-description to the capabilities of various data sources. This involves looking at the data fields that each API or database can supply and ensuring they align with the data fields outlined in the meta-description” [Devaux ¶ 260-261].
applying, at the network system, a large language model to the payload request and the candidate APIs to determine a selected API that performs the requested functionality, the large language model interpreting context and intent of the payload request to select a candidate API from the set of candidate APIs as the selected API based on the context and intent; “An aspect of the specification provides a search engine server wherein the meta-description is used by a large language model to select the plurality of nodes” [Devaux ¶ 10]. “A person skilled in the art can also appreciate how the structured queries generated by LLM engine 120 can be extremely sophisticated in nature, whereby travel management engine 122 may make a series of structured queries to travel actor engines 112” [Devaux ¶ 137]. “According to our illustrative example from FIG. 6, however, block 424 is reached from block 420, when the LLM Engine 120 determines that it has enough unstructured searching elements from message 504-1 and message 504-3 to prepare a fully structured travel query. Thus, according to our example in FIG. 6, block 424 comprises engaging LLM to prepare a draft response that also includes a structured travel query” [Devaux ¶ 126-127]. “An aspect of the specification provides a search engine server wherein the request intention is planning a travel itinerary and the plurality of sources includes selecting the API and/or the database hosted by a subset of a plurality of online travel solution providers within the full domain of sources” [Devaux ¶ 16]. “Node Selection: Once potential data sources are identified, the search engine server selects nodes that match the meta-description most closely. For instance, if the meta description calls for detailed cultural information about Buddhist temples, the search engine server may select nodes like cultural heritage databases and local tourism APIs that provide such data. Similarly, if the meta-description refers to a conversation aiming at giving inspiration, the server may select nodes favoring exploration and diversity of content (search APIs) over nodes favoring sales and depth of content (booking APIs)” [Devaux ¶ 262]. “FIG. 28 highlights the seamless integration of conversational AI with formal API endpoints in the generation of a chain of thought by a Large Language Model (LLM), specifically using GPT-4. API description 2800 can thus be used to configure LLM engine 120b as part of method 2500” [Devaux ¶ 310]. “Referring now to FIG. 29, a further variant on system 100, system 100a, and, system 100b is shown as system 100c … Search engine server 2900c accommodates conversations 1404c with users 124c via devices 116c. Conversations 1404c are processed using method 2500, creating one more query graphs 2904 at block 2528 during iterations through method 2500 throughout the course of conversation 1404c, eventually executing a query at block 2532. Such query graphs 2904 represent a chain of thought that can be used to efficiently effect intentions from conversation 1404c” [Devaux ¶ 320, fig. 29]. “The one or more travel contexts from block 308 include tables that provide contextual shifts for LLM engine 120, that situate LLM engine 120 in the context of a travel assistant and establish how the LLM engine 120 is to manage and respond to natural language travel queries received at various client devices 116 on behalf of users 124, as those queries are received by collaborator platform 104 and passed along to LLM engine 120” [Devaux ¶ 103]. “As a non-limiting illustrative example, interactions between a device 116, collaboration platform 104 and LLM engine 120 can result in natural language processing of messages, such as message 504-1, to ascertain an origin from an intent extracted from the message. Message 504-1 is a salient example, which includes the sentence "Hey, I need to book a Flight to Paris". Collaboration platform 104a and LLM engine 120a can thus derive the origin parameter "Paris" from message 504-1” [Devaux ¶ 145].
executing the selected API to generate a payload response including the requested functionality; “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265]. “Block 2532 comprises executing a query over the network based on the request intention using the query graph. This final step involves actively querying the selected sources through the network, utilizing the structured query graph to efficiently retrieve and compile data in response to the initial user request” [Devaux ¶ 278].
and transmitting the payload response to the client device. “Data Aggregation and Refinement: The search engine server collects the responses from the various nodes, aggregates the data, and refines it based on the meta description. This ensures that only relevant and useful information is included in the final response to the user's query” [Devaux ¶ 266]. “Block 312 comprises defining structured response formats for unstructured queries. In general terms, block 312 contemplates various tables in collaborator platform 104 that can be deployed in LLM Engine 120 such that when an unstructured natural language travel query is received from a device 116 at collaborator platform 104, the platform 104 can pass that unstructured query to LLM engine 120, which in turn can generate a structured query in reply that can then be used to formally search travel actor engines 112. The results from the travel actor engines 112 can then be returned to the originating device 116” [Devaux ¶ 109].
Devaux fails to teach applying, at the network system, a small language model to the payload request to determine a set of candidate APIs from a catalog based on embeddings generated by the small language model that map the natural language in the payload request to the functionality of the APIs in the catalog.
However, Papayiannis teaches applying, at the network system, a small language model to the payload request to determine a set of candidate APIs from a catalog based on (encodings) embeddings generated by the small language model that map the natural language in the payload request to the functionality of the APIs in the catalog, “The relevant API data 635 may be generated by the API shortlister component 620, which may be configured to retrieve one or more (e.g., top-k) relevant APIs associated with the user input data 102 or the current task” [Papayiannis ¶ 102]. “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 or the current task, APIs that are capable of performing the current task, etc.). In some embodiments, the API shortlister component 620 (or another component of the API shortlister component 620) may determine an encoded representation of the user input or the current task and compare (e.g., using cosine similarity) the encoded representation(s) to an encoded representation of an API description for the API to determine whether the API is semantically similar to the user input or the current task” [Papayiannis ¶ 103]. “The user input data 102 may be received at the encoder component 940 of the arbitrator component 882. The encoder component 940 may process the user input data 102 to generate encoded user input data 945 represented an encoded representation of the user input data 102 (e.g., a vectorized representation of the user input)” [Papayiannis ¶ 167].
Papayiannis is considered to be analogous to the claimed invention because it is in the same field of machine learning. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux to incorporate the teachings of Papayiannis and include applying, at the network system, a small language model to the payload request to determine a set of candidate APIs from a catalog based on (encodings) embeddings generated by the small language model that map the natural language in the payload request to the functionality of the APIs in the catalog. Doing so would allow for only APIs within a threshold level of similarity to be considered relevant. “If the value of semantic similarity meets or exceeds a threshold, the API (and, optionally, the API description) may be included in the relevant API data 635” [Papayiannis ¶ 103].
Devaux in view of Papayiannis fails to teach applying, at the network system, a small language model to the payload request to determine a set of candidate APIs from a catalog based on embeddings generated by the small language model that map the natural language in the payload request to the functionality of the APIs in the catalog.
However, Teng teaches applying, at the network system, a small language model to the payload request to determine a set of candidate APIs from a catalog based on embeddings generated by the small language model that map the natural language in the payload request to the functionality “The lightweight profile summary model 234 may be a lightweight language model or a specialized machine learning model designed to process and transform raw contextual data into a language or format that can be easily interpreted by other systems, such as LXMs. The "lightweight" characteristic signifies a smaller size and fewer parameters (e.g., hundreds of thousands to tens of millions of parameters, dozens to a few hundred tokens, etc.), enabling faster processing and reduced computational demands” [Teng ¶ 72]. “The term "embedding layer" is used herein to refer to a specialized layer within a neural network, typically at the input stage, that transforms continuous or discrete categorical values or tokens into continuous, high-dimensional vectors. An embedding layer may also transform high-dimensional data into low-dimensional vectors (e.g., using "dimensionality reduction" techniques, etc.), which may be particularly useful when the original data is complex or too large to handle efficiently. For lightweight language models, the embedding layer may convert tokens (typically low-dimensional entities) into high-dimensional vectors. An embedding layer may operate as a lookup table in which each unique token or category is mapped to a point in a continuous vector space. The vectors may be refined during the model's training phase to encapsulate the characteristics or attributes of the tokens in a manner that is conducive to the tasks the model is configured to perform. The term "token" is used herein to refer to a unit of information that an LXM may read as a single input during training and inference. Each token may represent any of a variety of different data types. For example, in text-centric models such as in LLMs, each token may represent a one or more textual element such as a paragraph(s), sentence(s), clause(s), word(s), sub-word(s), character(s), etc” [Teng ¶ 44-45].
Teng is considered to be analogous to the claimed invention because it is in the same field of machine learning. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux in view of Papayiannis to incorporate the teachings of Teng and include applying, at the network system, a small language model to the payload request to determine a set of candiate APIs from a catalog based on embeddings generated by the small language model that map the natural language in the payload request to the functionality. Doing so would allow for further optimization and efficiency. “Lightweight language models may be trained or optimized for specific tasks for which privacy or computational efficiency is a priority. The lightweight nature allows for quicker deployment and reduced latency during the inference stage, making them suitable for real-time applications or environments with limited computational resources … In some embodiments, lightweight language models may operate in tandem with more resource-intensive models, offloading certain tasks to optimize overall system performance” [Teng ¶ 36].
With regard to claim 22, Devaux in view of Papayiannis in view of Teng teaches the method of claim 21, as referenced above. Devaux fails to teach wherein selecting candidate APIs further comprises: determining, for each API of a plurality of APIs in the catalog, a score quantifying a likelihood the API is semantically or syntactically relevant to language in the payload request; and selecting the APIs having scores above a threshold score as the candidate APIs.
However, Papayiannis teaches:
wherein selecting candidate APIs further comprises: determining, for each API of a plurality of APIs in the catalog, a score quantifying a likelihood the API is semantically or syntactically relevant to language in the payload request; “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 or the current task, APIs that are capable of performing the current task, etc.) … compare (e.g., using cosine similarity) the encoded representation(s) to an encoded representation of an API description for the API to determine whether the API is semantically similar to the user input or the current task … If the value of semantic similarity (score) meets or exceeds a threshold, the API (and, optionally, the API description) may be included in the relevant API data 635. In some embodiments, the API shortlister component 620 may determine the relevant API data 635 further using contextual information, including the personalized context data 467, an accuracy/defect rate value associated with the APIs, and/or a historical latency value associated with the APIs (e.g., which may be included in the description of the API)” [Papayiannis ¶ 103].
and selecting the APIs having scores above a threshold score as the candidate APIs. “If the value of semantic similarity meets or exceeds a threshold, the API (and, optionally, the API description) may be included in the relevant API data 635” [Papayiannis ¶ 103].
With regard to claim 23, Devaux in view of Papayiannis in view of Teng teaches the method of claim 21, as referenced above. Devaux further teaches wherein the network system executes the selected API and transmits the payload response to the client device “Block 312 comprises defining structured response formats for unstructured queries. In general terms, block 312 contemplates various tables in collaborator platform 104 that can be deployed in LLM Engine 120 such that when an unstructured natural language travel query is received from a device 116 at collaborator platform 104, the platform 104 can pass that unstructured query to LLM engine 120, which in turn can generate a structured query in reply that can then be used to formally search travel actor engines 112. The results from the travel actor engines 112 can then be returned to the originating device 116” [Devaux ¶ 109].
With regard to claim 26, Devaux in view of Papayiannis teaches the method of claim 25, as referenced below. Devaux further teaches and the second model is a large language model that interprets natural language in the request to select a candidate API from the set based on its functionality. “An aspect of the specification provides a search engine server wherein the meta-description is used by a large language model to select the plurality of nodes” [Devaux ¶ 10]. “According to our illustrative example from FIG. 6, however, block 424 is reached from block 420, when the LLM Engine 120 determines that it has enough unstructured searching elements from message 504-1 and message 504-3 to prepare a fully structured travel query. Thus, according to our example in FIG. 6, block 424 comprises engaging LLM to prepare a draft response that also includes a structured travel query” [Devaux ¶ 126-127]. “An aspect of the specification provides a search engine server wherein the request intention is planning a travel itinerary and the plurality of sources includes selecting the API and/or the database hosted by a subset of a plurality of online travel solution providers within the full domain of sources” [Devaux ¶ 16]. “Node Selection: Once potential data sources are identified, the search engine server selects nodes that match the meta-description most closely. For instance, if the meta description calls for detailed cultural information about Buddhist temples, the search engine server may select nodes like cultural heritage databases and local tourism APIs that provide such data. Similarly, if the meta-description refers to a conversation aiming at giving inspiration, the server may select nodes favoring exploration and diversity of content (search APIs) over nodes favoring sales and depth of content (booking APIs)” [Devaux ¶ 262]. “As a non-limiting illustrative example, interactions between a device 116, collaboration platform 104 and LLM engine 120 can result in natural language processing of messages, such as message 504-1, to ascertain an origin from an intent extracted from the message. Message 504-1 is a salient example, which includes the sentence "Hey, I need to book a Flight to Paris". Collaboration platform 104a and LLM engine 120a can thus derive the origin parameter "Paris" from message 504-1” [Devaux ¶ 145].
Devaux fails to teach wherein the first model is a small language model that generates embeddings as the data representations that map natural language in the request to functionality of APIs in the API catalog.
However, Papayiannis teaches wherein the first model is a small language model that generates (encodings) embeddings as the data representations that map natural language in the request to functionality of APIs in the API catalog “The relevant API data 635 may be generated by the API shortlister component 620, which may be configured to retrieve one or more (e.g., top-k) relevant APIs associated with the user input data 102 or the current task” [Papayiannis ¶ 102]. “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 or the current task, APIs that are capable of performing the current task, etc.). In some embodiments, the API shortlister component 620 (or another component of the API shortlister component 620) may determine an encoded representation of the user input or the current task and compare (e.g., using cosine similarity) the encoded representation(s) to an encoded representation of an API description for the API to determine whether the API is semantically similar to the user input or the current task” [Papayiannis ¶ 103]. “The user input data 102 may be received at the encoder component 940 of the arbitrator component 882. The encoder component 940 may process the user input data 102 to generate encoded user input data 945 represented an encoded representation of the user input data 102 (e.g., a vectorized representation of the user input)” [Papayiannis ¶ 167].
Devaux in view of Papayiannis fails to teach wherein the first model is a small language model that generates embeddings as the data representations that map natural language in the request to functionality.
However, Teng teaches wherein the first model is a small language model that generates embeddings as the data representations that map natural language in the request to functionality “The lightweight profile summary model 234 may be a lightweight language model or a specialized machine learning model designed to process and transform raw contextual data into a language or format that can be easily interpreted by other systems, such as LXMs. The "lightweight" characteristic signifies a smaller size and fewer parameters (e.g., hundreds of thousands to tens of millions of parameters, dozens to a few hundred tokens, etc.), enabling faster processing and reduced computational demands” [Teng ¶ 72]. “The term "embedding layer" is used herein to refer to a specialized layer within a neural network, typically at the input stage, that transforms continuous or discrete categorical values or tokens into continuous, high-dimensional vectors. An embedding layer may also transform high-dimensional data into low-dimensional vectors (e.g., using "dimensionality reduction" techniques, etc.), which may be particularly useful when the original data is complex or too large to handle efficiently. For lightweight language models, the embedding layer may convert tokens (typically low-dimensional entities) into high-dimensional vectors. An embedding layer may operate as a lookup table in which each unique token or category is mapped to a point in a continuous vector space. The vectors may be refined during the model's training phase to encapsulate the characteristics or attributes of the tokens in a manner that is conducive to the tasks the model is configured to perform. The term "token" is used herein to refer to a unit of information that an LXM may read as a single input during training and inference. Each token may represent any of a variety of different data types. For example, in text-centric models such as in LLMs, each token may represent a one or more textual element such as a paragraph(s), sentence(s), clause(s), word(s), sub-word(s), character(s), etc” [Teng ¶ 44-45].
Teng is considered to be analogous to the claimed invention because it is in the same field of machine learning. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux in view of Papayiannis to incorporate the teachings of Teng and include wherein the first model is a small language model that generates embeddings as the data representations that map natural language in the request to functionality. Doing so would allow for further optimization and efficiency. “Lightweight language models may be trained or optimized for specific tasks for which privacy or computational efficiency is a priority. The lightweight nature allows for quicker deployment and reduced latency during the inference stage, making them suitable for real-time applications or environments with limited computational resources … In some embodiments, lightweight language models may operate in tandem with more resource-intensive models, offloading certain tasks to optimize overall system performance” [Teng ¶ 36].
With regard to claim 33, Devaux teaches:
A method for generating a payload response for a requested functionality in a system environment, the method comprising: “Block 312 comprises defining structured response formats for unstructured queries. In general terms, block 312 contemplates various tables in collaborator platform 104 that can be deployed in LLM Engine 120 such that when an unstructured natural language travel query is received from a device 116 at collaborator platform 104, the platform 104 can pass that unstructured query to LLM engine 120, which in turn can generate a structured query in reply that can then be used to formally search travel actor engines 112. The results from the travel actor engines 112 can then be returned to the originating device 116” [Devaux ¶ 109]. “FIG. 28 is an illustrative representation showcasing the application of a formal API description in the generation of a chain of thought” [Devaux ¶ 74, fig. 28].
receiving, at a network system, a payload request from a client device, the payload request comprising a natural language request for the requested functionality; “FIG. 28 illustrates the LLM's capacity to engage in a contextually adaptive dialogue, employing its reasoning capabilities to sequence API calls and data processing tasks in response to a user's natural language query” [Devaux ¶ 310, fig. 28]. “The one or more travel contexts from block 308 include tables that provide contextual shifts for LLM engine 120, that situate LLM engine 120 in the context of a travel assistant and establish how the LLM engine 120 is to manage and respond to natural language travel queries received at various client devices 116 on behalf of users 124, as those queries are received by collaborator platform 104 and passed along to LLM engine 120” [Devaux ¶ 103].
applying, at the network system, a small language model to the payload request to determine a plurality of relevant APIs from a catalog based on embeddings generated by the small language model that map(ping) the natural language in the payload request to the functionality of the APIs in the catalog, “Block 2508 comprises determining at least one parameter from a request intention within the conversational session” [Devaux ¶ 251]. “Block 2512 comprises determining a meta-description based on the parameters. This involves synthesizing a concise overview of the data related to the identified parameters, which serves to contextualize and streamline the selection process in subsequent steps” [Devaux ¶ 257]. “Block 2516 comprises selecting, based on the at least one parameter and the meta-description, a plurality of nodes representing sources within a full domain of sources. These sources may include, but are not limited to, a function call via an application programming interface (API), a database, and a large language model. The meta-description acts as a set of criteria that enables the system to understand and categorize the information required from different sources. The meta-description guides the actual search engine server (e.g. Travel management engine 122b) in identifying which nodes (e.g. Travel actor engines 112) are relevant for the search query, and what kind of information to retrieve from them” [Devaux ¶ 258-259]. “Identification of Data Sources: The meta-description can outline the types of data needed to satisfy the user's query. Based on the criteria specified in the meta-description, the search engine server determines which APIs (relevant APIs), databases, or language models have the potential to provide the required information. Matching Criteria with Capabilities: The search engine server compares the criteria from the meta-description to the capabilities of various data sources. This involves looking at the data fields that each API or database can supply and ensuring they align with the data fields outlined in the meta-description” [Devaux ¶ 260-261].
wherein: each of relevant APIs of the plurality of relevant APIs, when executed by the network system, provide a partial functionality different from the requested functionality; “FIG. 28 is an illustrative representation showcasing the application of a formal API description 2800 in the generation of a chain of thought by a Large Language Model (LLM), specifically using GPT. API description 2800 exemplifies how GPT-4 processes structured API data to logically construct a step-by-step solution that aligns with the methodological innovations of system 100b. FIG. 28 illustrates the LLM's capacity to engage in a contextually adaptive dialogue, employing its reasoning capabilities to sequence API calls and data processing tasks in response to a user's natural language query. The API description of FIG. 28 serves as a visualization of the advanced cognitive interactions between GPT-4 and various data sources within system 100b. FIG. 28 highlights the seamless integration of conversational AI with formal API endpoints in the generation of a chain of thought by a Large Language Model (LLM), specifically using GPT-4” [Devaux ¶ 310, fig. 28]. “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137].
and two or more of the relevant APIs in the plurality form an ordered sequence of APIs that, when executed by the network system, provide the requested functionality; “FIG. 28 is an illustrative representation showcasing the application of a formal API description 2800 in the generation of a chain of thought by a Large Language Model (LLM), specifically using GPT. API description 2800 exemplifies how GPT-4 processes structured API data to logically construct a step-by-step solution that aligns with the methodological innovations of system 100b. FIG. 28 illustrates the LLM's capacity to engage in a contextually adaptive dialogue, employing its reasoning capabilities to sequence API calls and data processing tasks in response to a user's natural language query. The API description of FIG. 28 serves as a visualization of the advanced cognitive interactions between GPT-4 and various data sources within system 100b. FIG. 28 highlights the seamless integration of conversational AI with formal API endpoints in the generation of a chain of thought by a Large Language Model (LLM), specifically using GPT-4” [Devaux ¶ 310, fig. 28]. “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137].
applying, at the network system, a large language model to the payload request and the relevant APIs to determine the ordered sequence of APIs comprising two or more of the relevant APIs that performs the requested functionality when executed by the network system, “An aspect of the specification provides a search engine server wherein the meta-description is used by a large language model to select the plurality of nodes” [Devaux ¶ 10]. “A person skilled in the art can also appreciate how the structured queries generated by LLM engine 120 can be extremely sophisticated in nature, whereby travel management engine 122 may make a series of structured queries to travel actor engines 112” [Devaux ¶ 137]. “According to our illustrative example from FIG. 6, however, block 424 is reached from block 420, when the LLM Engine 120 determines that it has enough unstructured searching elements from message 504-1 and message 504-3 to prepare a fully structured travel query. Thus, according to our example in FIG. 6, block 424 comprises engaging LLM to prepare a draft response that also includes a structured travel query” [Devaux ¶ 126-127]. “Node Selection: Once potential data sources are identified, the search engine server selects nodes that match the meta-description most closely. For instance, if the meta description calls for detailed cultural information about Buddhist temples, the search engine server may select nodes like cultural heritage databases and local tourism APIs that provide such data. Similarly, if the meta-description refers to a conversation aiming at giving inspiration, the server may select nodes favoring exploration and diversity of content (search APIs) over nodes favoring sales and depth of content (booking APIs)” [Devaux ¶ 262]. “Node combination: Once the server has selected nodes or data sources, the server defines in which sequence and/or conditions to execute the queries on the selected nodes. For instance, queries on data sources providing information on Buddhist temples can be executed in parallel and the results can be grouped together. Moreover, the server may describe how the search results of a data source may be used, in conjunction with other elements in the meta description, to form the input of a subsequent query on another data source. For example, a subsequent call to the API of a local tourism board may be necessary to retrieve the dates of the occurrence of a yearly Buddhist festival” [Devaux ¶ 264].
wherein the large language model selects the two or more relevant APIs of the ordered sequence of APIs by: interpreting context and intent of the payload request to select each relevant API from the plurality for the ordered sequence based on the context and intent, “FIG. 28 highlights the seamless integration of conversational AI with formal API endpoints in the generation of a chain of thought by a Large Language Model (LLM), specifically using GPT-4. API description 2800 can thus be used to configure LLM engine 120b as part of method 2500” [Devaux ¶ 310]. “Referring now to FIG. 29, a further variant on system 100, system 100a, and, system 100b is shown as system 100c … Search engine server 2900c accommodates conversations 1404c with users 124c via devices 116c. Conversations 1404c are processed using method 2500, creating one more query graphs 2904 at block 2528 during iterations through method 2500 throughout the course of conversation 1404c, eventually executing a query at block 2532. Such query graphs 2904 represent a chain of thought that can be used to efficiently effect intentions from conversation 1404c” [Devaux ¶ 320, fig. 29]. “The one or more travel contexts from block 308 include tables that provide contextual shifts for LLM engine 120, that situate LLM engine 120 in the context of a travel assistant and establish how the LLM engine 120 is to manage and respond to natural language travel queries received at various client devices 116 on behalf of users 124, as those queries are received by collaborator platform 104 and passed along to LLM engine 120” [Devaux ¶ 103]. “As a non-limiting illustrative example, interactions between a device 116, collaboration platform 104 and LLM engine 120 can result in natural language processing of messages, such as message 504-1, to ascertain an origin from an intent extracted from the message. Message 504-1 is a salient example, which includes the sentence "Hey, I need to book a Flight to Paris". Collaboration platform 104a and LLM engine 120a can thus derive the origin parameter "Paris" from message 504-1” [Devaux ¶ 145]. “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137].
and selecting each relevant API for the ordered sequence of APIs such that the partial functionality of each relevant API, when generated in an ordered sequence, causes the ordered sequence of APIs to provide the requested functionality; “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137]. “Configuration of Query Parameters: The search engine server then configures the query parameters for each selected node based on the meta-description. It formats the search queries in a way that the APIs and databases can understand and respond to, ensuring that the information retrieved will be structured according to the meta-description's criteria. Node combination: Once the server has selected nodes or data sources, the server defines in which sequence and/or conditions to execute the queries on the selected nodes. For instance, queries on data sources providing information on Buddhist temples can be executed in parallel and the results can be grouped together. Moreover, the server may describe how the search results of a data source may be used, in conjunction with other elements in the meta description, to form the input of a subsequent query on another data source. For example, a subsequent call to the API of a local tourism board may be necessary to retrieve the dates of the occurrence of a yearly Buddhist festival” [Devaux ¶ 263-264].
executing the ordered sequence of APIs to generate a payload response including the requested functionality; “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265]. “Block 2532 comprises executing a query over the network based on the request intention using the query graph. This final step involves actively querying the selected sources through the network, utilizing the structured query graph to efficiently retrieve and compile data in response to the initial user request” [Devaux ¶ 278]. “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137].
and transmitting the payload response to the client device. “Data Aggregation and Refinement: The search engine server collects the responses from the various nodes, aggregates the data, and refines it based on the meta description. This ensures that only relevant and useful information is included in the final response to the user's query” [Devaux ¶ 266]. “Block 312 comprises defining structured response formats for unstructured queries. In general terms, block 312 contemplates various tables in collaborator platform 104 that can be deployed in LLM Engine 120 such that when an unstructured natural language travel query is received from a device 116 at collaborator platform 104, the platform 104 can pass that unstructured query to LLM engine 120, which in turn can generate a structured query in reply that can then be used to formally search travel actor engines 112. The results from the travel actor engines 112 can then be returned to the originating device 116” [Devaux ¶ 109].
Devaux fails to teach applying, at the network system, a small language model to the payload request to determine a plurality of relevant APIs from a catalog based on embeddings generated by the small language model that map the natural language in the payload request to the functionality of the APIs in the catalog.
However, Papayiannis teaches applying, at the network system, a small language model to the payload request to determine a plurality of relevant APIs from a catalog based on (encodings) embeddings generated by the small language model that map the natural language in the payload request to the functionality of the APIs in the catalog, “The relevant API data 635 may be generated by the API shortlister component 620, which may be configured to retrieve one or more (e.g., top-k) relevant APIs associated with the user input data 102 or the current task” [Papayiannis ¶ 102]. “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 or the current task, APIs that are capable of performing the current task, etc.). In some embodiments, the API shortlister component 620 (or another component of the API shortlister component 620) may determine an encoded representation of the user input or the current task and compare (e.g., using cosine similarity) the encoded representation(s) to an encoded representation of an API description for the API to determine whether the API is semantically similar to the user input or the current task” [Papayiannis ¶ 103]. “The user input data 102 may be received at the encoder component 940 of the arbitrator component 882. The encoder component 940 may process the user input data 102 to generate encoded user input data 945 represented an encoded representation of the user input data 102 (e.g., a vectorized representation of the user input)” [Papayiannis ¶ 167].
Papayiannis is considered to be analogous to the claimed invention because it is in the same field of machine learning. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux to incorporate the teachings of Papayiannis and include applying, at the network system, a small language model to the payload request to determine a plurality of relevant APIs from a catalog based on (encodings) embeddings generated by the small language model that map the natural language in the payload request to the functionality of the APIs in the catalog,. Doing so would allow for only APIs within a threshold level of similarity to be considered relevant. “If the value of semantic similarity meets or exceeds a threshold, the API (and, optionally, the API description) may be included in the relevant API data 635” [Papayiannis ¶ 103].
Devaux in view of Papayiannis fails to teach applying, at the network system, a small language model to the payload request to determine a plurality of relevant APIs from a catalog based on embeddings generated by the small language model that map the natural language in the payload request to the functionality of the APIs in the catalog.
However, Teng teaches applying, at the network system, a small language model to the payload request to determine a plurality of relevant APIs from a catalog based on embeddings generated by the small language model that map the natural language in the payload request to the functionality “The lightweight profile summary model 234 may be a lightweight language model or a specialized machine learning model designed to process and transform raw contextual data into a language or format that can be easily interpreted by other systems, such as LXMs. The "lightweight" characteristic signifies a smaller size and fewer parameters (e.g., hundreds of thousands to tens of millions of parameters, dozens to a few hundred tokens, etc.), enabling faster processing and reduced computational demands” [Teng ¶ 72]. “The term "embedding layer" is used herein to refer to a specialized layer within a neural network, typically at the input stage, that transforms continuous or discrete categorical values or tokens into continuous, high-dimensional vectors. An embedding layer may also transform high-dimensional data into low-dimensional vectors (e.g., using "dimensionality reduction" techniques, etc.), which may be particularly useful when the original data is complex or too large to handle efficiently. For lightweight language models, the embedding layer may convert tokens (typically low-dimensional entities) into high-dimensional vectors. An embedding layer may operate as a lookup table in which each unique token or category is mapped to a point in a continuous vector space. The vectors may be refined during the model's training phase to encapsulate the characteristics or attributes of the tokens in a manner that is conducive to the tasks the model is configured to perform. The term "token" is used herein to refer to a unit of information that an LXM may read as a single input during training and inference. Each token may represent any of a variety of different data types. For example, in text-centric models such as in LLMs, each token may represent a one or more textual element such as a paragraph(s), sentence(s), clause(s), word(s), sub-word(s), character(s), etc” [Teng ¶ 44-45].
Teng is considered to be analogous to the claimed invention because it is in the same field of machine learning. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux in view of Papayiannis to incorporate the teachings of Teng and include applying, at the network system, a small language model to the payload request to determine a plurality of relevant APIs from a catalog based on embeddings generated by the small language model that map the natural language in the payload request to the functionality. Doing so would allow for further optimization and efficiency. “Lightweight language models may be trained or optimized for specific tasks for which privacy or computational efficiency is a priority. The lightweight nature allows for quicker deployment and reduced latency during the inference stage, making them suitable for real-time applications or environments with limited computational resources … In some embodiments, lightweight language models may operate in tandem with more resource-intensive models, offloading certain tasks to optimize overall system performance” [Teng ¶ 36].
With regard to claim 34, Devaux in view of Papayiannis in view of Teng teaches the method of claim 33, as referenced above. Devaux further teaches further comprising: generating the plurality of relevant APIs by applying, at the network system, a small language model to the payload request to determine the plurality of relevant APIs from an API catalog comprising a plurality of APIs; “Block 2508 comprises determining at least one parameter from a request intention within the conversational session” [Devaux ¶ 251]. “Block 2512 comprises determining a meta-description based on the parameters. This involves synthesizing a concise overview of the data related to the identified parameters, which serves to contextualize and streamline the selection process in subsequent steps” [Devaux ¶ 257]. “Block 2516 comprises selecting, based on the at least one parameter and the meta-description, a plurality of nodes representing sources within a full domain of sources. These sources may include, but are not limited to, a function call via an application programming interface (API), a database, and a large language model. The meta-description acts as a set of criteria that enables the system to understand and categorize the information required from different sources. The meta-description guides the actual search engine server (e.g. Travel management engine 122b) in identifying which nodes (e.g. Travel actor engines 112) are relevant for the search query, and what kind of information to retrieve from them” [Devaux ¶ 258-259]. “Identification of Data Sources: The meta-description can outline the types of data needed to satisfy the user's query. Based on the criteria specified in the meta-description, the search engine server determines which APIs (relevant APIs), databases, or language models have the potential to provide the required information. Matching Criteria with Capabilities: The search engine server compares the criteria from the meta-description to the capabilities of various data sources. This involves looking at the data fields that each API or database can supply and ensuring they align with the data fields outlined in the meta-description” [Devaux ¶ 260-261].
Devaux fails to teach generating the plurality of relevant APIs by applying, at the network system, a small language model to the payload request to determine the plurality of relevant APIs from an API catalog comprising a plurality of APIs; and selecting the plurality of relevant APIs based on embeddings generated by the small language model that map the natural language in the payload request to the functionality of the plurality of APIs in the catalog.
However, Papayiannis teaches by applying, at the network system, a small language model to the payload request to determine the plurality of relevant APIs from an API catalog comprising a plurality of APIs; and selecting the plurality of relevant APIs based on (encodings) embeddings generated by the small language model that map the natural language in the payload request to the functionality of the plurality of APIs in the catalog. “The relevant API data 635 may be generated by the API shortlister component 620, which may be configured to retrieve one or more (e.g., top-k) relevant APIs associated with the user input data 102 or the current task” [Papayiannis ¶ 102]. “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 or the current task, APIs that are capable of performing the current task, etc.). In some embodiments, the API shortlister component 620 (or another component of the API shortlister component 620) may determine an encoded representation of the user input or the current task and compare (e.g., using cosine similarity) the encoded representation(s) to an encoded representation of an API description for the API to determine whether the API is semantically similar to the user input or the current task” [Papayiannis ¶ 103]. “The user input data 102 may be received at the encoder component 940 of the arbitrator component 882. The encoder component 940 may process the user input data 102 to generate encoded user input data 945 represented an encoded representation of the user input data 102 (e.g., a vectorized representation of the user input)” [Papayiannis ¶ 167].
Devaux in view of Papayiannis fails to teach applying, at the network system, a small language model to the payload request to determine the plurality of relevant APIs from an API catalog comprising a plurality of APIs; and selecting the plurality of relevant APIs based on embeddings generated by the small language model that map the natural language in the payload request to the functionality.
However, Teng teaches applying, at the network system, a small language model to the payload request to determine the plurality of relevant APIs from an API catalog comprising a plurality of APIs; and selecting the plurality of relevant APIs based on embeddings generated by the small language model that map the natural language in the payload request to the functionality “The lightweight profile summary model 234 may be a lightweight language model or a specialized machine learning model designed to process and transform raw contextual data into a language or format that can be easily interpreted by other systems, such as LXMs. The "lightweight" characteristic signifies a smaller size and fewer parameters (e.g., hundreds of thousands to tens of millions of parameters, dozens to a few hundred tokens, etc.), enabling faster processing and reduced computational demands” [Teng ¶ 72]. “The term "embedding layer" is used herein to refer to a specialized layer within a neural network, typically at the input stage, that transforms continuous or discrete categorical values or tokens into continuous, high-dimensional vectors. An embedding layer may also transform high-dimensional data into low-dimensional vectors (e.g., using "dimensionality reduction" techniques, etc.), which may be particularly useful when the original data is complex or too large to handle efficiently. For lightweight language models, the embedding layer may convert tokens (typically low-dimensional entities) into high-dimensional vectors. An embedding layer may operate as a lookup table in which each unique token or category is mapped to a point in a continuous vector space. The vectors may be refined during the model's training phase to encapsulate the characteristics or attributes of the tokens in a manner that is conducive to the tasks the model is configured to perform. The term "token" is used herein to refer to a unit of information that an LXM may read as a single input during training and inference. Each token may represent any of a variety of different data types. For example, in text-centric models such as in LLMs, each token may represent a one or more textual element such as a paragraph(s), sentence(s), clause(s), word(s), sub-word(s), character(s), etc” [Teng ¶ 44-45].
With regard to claim 36, Devaux in view of Papayiannis teaches the method of claim 33, as referenced above. Devaux further teaches:
wherein one or more of the sequenced APIs are stored on an additional network system, “An aspect of the specification provides a search engine server wherein the request intention is planning a travel itinerary and the plurality of sources includes selecting the API and/or the database hosted by a subset of a plurality of online travel solution providers within the full domain of sources” [Devaux ¶ 16]. “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265]. “Any structured format that can be used for a structured query that is understandable to an application programming interface ("API") or the like for travel management engine 122 and/or travel actor engines 112 is within the scope of this specification” [Devaux ¶ 129, fig. 1 Examiner notes travel actor engines 122 in figure 1].
and executing the sequenced API executes the sequenced on API on the additional network system. “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265]. “Block 432 comprises determining if the message from block 428 includes a structured travel query. A "no" determination leads to block 444 and thus the message drafted at block 424 is sent directly to the originating client device 116. A "yes" determination at block 432 leads to block 436, at which point the structured travel query is sent to external sources for fulfillment” [Devaux ¶ 131].
Claim(s) 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Devaux et al. US 2024/0370505 A1 (hereafter Devaux) in view of Papayiannis et al. US 2025/0104693 A1 (hereafter Papayiannis) in view of Teng et al. US 2025/0131190 A1 (hereafter Teng) in view of Madhur et al. US 2024/0012923 A1 (hereafter Madhur).
With regard to claim 24, Devaux in view of Papayiannis in view of Teng teaches the method of claim 21, as referenced above. Devaux further teaches:
further comprising: providing a location of the selected API to the client device; “One or more deeplinks may also be returned at block 1920 to a specific travel booking engine 112a to allow completion of the booking. For example: https://www.kayak.fr/flights/LHR-NRT /2024-01-14/2024-0121 ?sort=price_a” [Devaux ¶ 185].
and wherein a system hosting the location executes the selected API “An aspect of the specification provides a search engine server wherein the request intention is planning a travel itinerary and the plurality of sources includes selecting the API and/or the database hosted by a subset of a plurality of online travel solution providers within the full domain of sources” [Devaux ¶ 16]. “Furthermore, when a device 116a actually makes a selection from results returned at block 1920 and completes a booking, sparse data domain 1708 can be updated so as to retain the offers that are selected most often” [Devaux ¶ 198].
Devaux in view of Papayiannis in view of Teng fails to explicitly teach and the system transmits the payload response to the client device.
However, Madhur teaches and wherein a system hosting the location executes the selected API and the system transmits the payload response to the client device. “The API server 224 generates an API response 242 based on the operations performed (or not performed) by the service 228 in response to the API request 234 received from the client device 232. The API server 224 transmits the API response 242 to the client device 232 to fulfill the API request 234” [Madhur ¶ 73, fig. 2].
Madhur is considered to be analogous to the claimed invention because it is in the same field of remote procedure calls. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux in view of Papayiannis in view of Teng to incorporate the teachings of Madhur and include the system transmits the payload response to the client device. Doing so would allow for the fulfillment of an API request by the host server. “The API server 224 transmits the API response 242 to the client device 232 to fulfill the API request 234” [Madhur ¶ 73].
Claim(s) 25 and 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Devaux et al. US 2024/0370505 A1 (hereafter Devaux) in view of Papayiannis et al. US 2025/0104693 A1 (hereafter Papayiannis).
With regard to claim 25, Devaux teaches:
A method for generating a payload response for a requested functionality in a system environment, the method comprising: “Block 312 comprises defining structured response formats for unstructured queries. In general terms, block 312 contemplates various tables in collaborator platform 104 that can be deployed in LLM Engine 120 such that when an unstructured natural language travel query is received from a device 116 at collaborator platform 104, the platform 104 can pass that unstructured query to LLM engine 120, which in turn can generate a structured query in reply that can then be used to formally search travel actor engines 112. The results from the travel actor engines 112 can then be returned to the originating device 116” [Devaux ¶ 109]. “FIG. 28 is an illustrative representation showcasing the application of a formal API description in the generation of a chain of thought” [Devaux ¶ 74, fig. 28].
receiving, at a network system, a natural language request for a payload from a client device; “FIG. 28 illustrates the LLM's capacity to engage in a contextually adaptive dialogue, employing its reasoning capabilities to sequence API calls and data processing tasks in response to a user's natural language query” [Devaux ¶ 310, fig. 28]. “The one or more travel contexts from block 308 include tables that provide contextual shifts for LLM engine 120, that situate LLM engine 120 in the context of a travel assistant and establish how the LLM engine 120 is to manage and respond to natural language travel queries received at various client devices 116 on behalf of users 124, as those queries are received by collaborator platform 104 and passed along to LLM engine 120” [Devaux ¶ 103].
applying, at the network system, (processing) a first model to the natural language request to determine a set of candidate APIs from an API catalog, the determination comprising: generating, with the first model, data representations that map natural language in the request to functionality of APIs in the catalog, and selecting, based on the representations, candidate APIs, wherein the selected APIs have at least a threshold level of similarity between the natural language in the request and functionality of APIs in the API catalog; “Block 2508 comprises determining at least one parameter from a request intention within the conversational session. This block involves analyzing messages 1504 to identify key elements that will guide the subsequent processes, ensuring that the server's responses are accurately aligned with the user's needs” [Devaux ¶ 251]. “Block 2512 comprises determining a meta-description (data representations) based on the parameters. This involves synthesizing a concise overview of the data related to the identified parameters, which serves to contextualize and streamline the selection process in subsequent steps” [Devaux ¶ 257]. “Block 2516 comprises selecting, based on the at least one parameter and the meta-description, a plurality of nodes representing sources within a full domain of sources. These sources may include, but are not limited to, a function call via an application programming interface (API), a database, and a large language model. The meta-description acts as a set of criteria that enables the system to understand and categorize the information required from different sources. The meta-description guides the actual search engine server (e.g. Travel management engine 122b) in identifying which nodes (e.g. Travel actor engines 112) are relevant for the search query, and what kind of information to retrieve from them” [Devaux ¶ 258-259]. “Identification of Data Sources: The meta-description can outline the types of data needed to satisfy the user's query. Based on the criteria specified in the meta-description, the search engine server determines which APIs (candidate APIs), databases, or language models have the potential to provide the required information. Matching Criteria with Capabilities: The search engine server compares the criteria from the meta-description to the capabilities of various data sources. This involves looking at the data fields that each API or database can supply and ensuring they align with the data fields outlined in the meta-description” [Devaux ¶ 260-261].
applying, at the network system, a second model to the natural language request and the candidate APIs to determine a selected API that performs the requested functionality represented in the natural language request, the second model interpreting the natural language request to select a most relevant candidate API from the set of candidate APIs as the selected API; “An aspect of the specification provides a search engine server wherein the meta-description is used by a large language model to select the plurality of nodes” [Devaux ¶ 10]. “A person skilled in the art can also appreciate how the structured queries generated by LLM engine 120 can be extremely sophisticated in nature, whereby travel management engine 122 may make a series of structured queries to travel actor engines 112” [Devaux ¶ 137]. “According to our illustrative example from FIG. 6, however, block 424 is reached from block 420, when the LLM Engine 120 determines that it has enough unstructured searching elements from message 504-1 and message 504-3 to prepare a fully structured travel query. Thus, according to our example in FIG. 6, block 424 comprises engaging LLM to prepare a draft response that also includes a structured travel query” [Devaux ¶ 126-127]. “An aspect of the specification provides a search engine server wherein the request intention is planning a travel itinerary and the plurality of sources includes selecting the API and/or the database hosted by a subset of a plurality of online travel solution providers within the full domain of sources” [Devaux ¶ 16]. “Node Selection: Once potential data sources are identified, the search engine server selects nodes that match the meta-description most closely. For instance, if the meta description calls for detailed cultural information about Buddhist temples, the search engine server may select nodes like cultural heritage databases and local tourism APIs that provide such data. Similarly, if the meta-description refers to a conversation aiming at giving inspiration, the server may select nodes favoring exploration and diversity of content (search APIs) over nodes favoring sales and depth of content (booking APIs)” [Devaux ¶ 262]. “The one or more travel contexts from block 308 include tables that provide contextual shifts for LLM engine 120, that situate LLM engine 120 in the context of a travel assistant and establish how the LLM engine 120 is to manage and respond to natural language travel queries received at various client devices 116 on behalf of users 124, as those queries are received by collaborator platform 104 and passed along to LLM engine 120” [Devaux ¶ 103]. “As a non-limiting illustrative example, interactions between a device 116, collaboration platform 104 and LLM engine 120 can result in natural language processing of messages, such as message 504-1, to ascertain an origin from an intent extracted from the message. Message 504-1 is a salient example, which includes the sentence "Hey, I need to book a Flight to Paris". Collaboration platform 104a and LLM engine 120a can thus derive the origin parameter "Paris" from message 504-1” [Devaux ¶ 145].
executing the selected API to generate a response including the requested functionality; “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265]. “Block 2532 comprises executing a query over the network based on the request intention using the query graph. This final step involves actively querying the selected sources through the network, utilizing the structured query graph to efficiently retrieve and compile data in response to the initial user request” [Devaux ¶ 278].
and transmitting the generated response to the client device. “Data Aggregation and Refinement: The search engine server collects the responses from the various nodes, aggregates the data, and refines it based on the meta description. This ensures that only relevant and useful information is included in the final response to the user's query” [Devaux ¶ 266]. “Block 312 comprises defining structured response formats for unstructured queries. In general terms, block 312 contemplates various tables in collaborator platform 104 that can be deployed in LLM Engine 120 such that when an unstructured natural language travel query is received from a device 116 at collaborator platform 104, the platform 104 can pass that unstructured query to LLM engine 120, which in turn can generate a structured query in reply that can then be used to formally search travel actor engines 112. The results from the travel actor engines 112 can then be returned to the originating device 116” [Devaux ¶ 109].
Devaux fails to explicitly teach applying, at the network system, a first model to the natural language request to determine a set of candidate APIs from an API catalog, the determination comprising: generating, with the first model, data representations that map natural language in the request to functionality of APIs in the catalog, and selecting, based on the representations, candidate APIs, wherein the selected APIs have at least a threshold level of similarity between the natural language in the request and functionality of APIs in the API catalog.
However, Papayiannis teaches applying, at the network system, a first model to the natural language request to determine a set of candidate APIs from an API catalog, the determination comprising: generating, with the first model, data representations that map natural language in the request to functionality of APIs in the catalog, and selecting, based on the representations, candidate APIs, “The relevant API data 635 may be generated by the API shortlister component 620, which may be configured to retrieve one or more (e.g., top-k) relevant APIs associated with the user input data 102 or the current task” [Papayiannis ¶ 102]. “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 or the current task, APIs that are capable of performing the current task, etc.). In some embodiments, the API shortlister component 620 (or another component of the API shortlister component 620) may determine an encoded representation of the user input or the current task and compare (e.g., using cosine similarity) the encoded representation(s) to an encoded representation of an API description for the API to determine whether the API is semantically similar to the user input or the current task” [Papayiannis ¶ 103]. “The user input data 102 may be received at the encoder component 940 of the arbitrator component 882. The encoder component 940 may process the user input data 102 to generate encoded user input data 945 represented an encoded representation of the user input data 102 (e.g., a vectorized representation of the user input)” [Papayiannis ¶ 167].
wherein the selected APIs have at least a threshold level of similarity between the natural language in the request and functionality of APIs in the API catalog; “… compare (e.g., using cosine similarity) the encoded representation(s) to an encoded representation of an API description for the API to determine whether the API is semantically similar to the user input or the current task … If the value of semantic similarity meets or exceeds a threshold, the API (and, optionally, the API description) may be included in the relevant API data 635” [Papayiannis ¶ 103].
Papayiannis is considered to be analogous to the claimed invention because it is in the same field of machine learning. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux to incorporate the teachings of Papayiannis and include applying, at the network system, a first model to the natural language request to determine a set of candidate APIs from an API catalog, the determination comprising: generating, with the first model, data representations that map natural language in the request to functionality of APIs in the catalog, and selecting, based on the representations, candidate APIs, wherein the selected APIs have at least a threshold level of similarity between the natural language in the request and functionality of APIs in the API catalog. Doing so would allow for only APIs within a threshold level of similarity to be considered relevant. “If the value of semantic similarity meets or exceeds a threshold, the API (and, optionally, the API description) may be included in the relevant API data 635” [Papayiannis ¶ 103].
With regard to claim 27, Devaux in view of Papayiannis teaches the method of claim 25, as referenced above. Devaux further teaches:
wherein the selected API is stored on an additional network system “An aspect of the specification provides a search engine server wherein the request intention is planning a travel itinerary and the plurality of sources includes selecting the API and/or the database hosted by a subset of a plurality of online travel solution providers within the full domain of sources” [Devaux ¶ 16]. “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265]. “Any structured format that can be used for a structured query that is understandable to an application programming interface ("API") or the like for travel management engine 122 and/or travel actor engines 112 (additional network systems) is within the scope of this specification” [Devaux ¶ 129, fig. 1 Examiner notes travel actor engines 122 in figure 1].
and executing the selected API comprises executing the selected API on the additional network system. “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265]. “Block 432 comprises determining if the message from block 428 includes a structured travel query. A "no" determination leads to block 444 and thus the message drafted at block 424 is sent directly to the originating client device 116. A "yes" determination at block 432 leads to block 436, at which point the structured travel query is sent to external sources for fulfillment” [Devaux ¶ 131].
Claim(s) 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Devaux et al. US 2024/0370505 A1 (hereafter Devaux) in view of Papayiannis et al. US 2025/0104693 A1 (hereafter Papayiannis) in view of Kim et al. US 2023/0169312 A1 (hereafter Kim).
With regard to claim 28, Devaux in view of Papayiannis teaches the method of claim 25, as referenced above. Devaux further teaches:
wherein the selected API is stored on an additional network system “An aspect of the specification provides a search engine server wherein the request intention is planning a travel itinerary and the plurality of sources includes selecting the API and/or the database hosted by a subset of a plurality of online travel solution providers within the full domain of sources” [Devaux ¶ 16]. “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265]. “Any structured format that can be used for a structured query that is understandable to an application programming interface ("API") or the like for travel management engine 122 and/or travel actor engines 112 (additional network systems) is within the scope of this specification” [Devaux ¶ 129, fig. 1 Examiner notes travel actor engines 122 in figure 1].
and executing the selected API “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265].
Devaux in view of Papayiannis fails to explicitly teach and executing the selected API comprises: providing the selected API from the additional network system to the network system; and executing the selected API on the network system.
However, Kim teaches:
and executing the selected (code) API comprises: providing the selected (code) API from the additional network system to the network system; and executing the selected (code) API on the network system. “At least part of the application programs may be downloaded from an external server through wireless communication. The application program may be stored in the memory 220, may be installed in the decoding system 200, and may be driven by the processor 230 to perform an operation (or function) of the decoding system 200” [Kim ¶ 47].
Kim is considered to be analogous to the claimed invention because it is in the same field of machine learning. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux in view of Papayiannis to incorporate the teachings of Kim and include and executing the selected API comprises: providing the selected API from the additional network system to the network system; and executing the selected API on the network system. Doing so would allow for the network system to execute queries locally [Kim ¶ 47].
Claim(s) 35 is/are rejected under 35 U.S.C. 103 as being unpatentable over Devaux et al. US 2024/0370505 A1 (hereafter Devaux) in view of Papayiannis et al. US 2025/0104693 A1 (hereafter Papayiannis) in view of Teng et al. US 2025/0131190 A1 (hereafter Teng) in view of Patil et al. US 2022/0310085 A1 (hereafter Patil).
With regard to claim 35, Devaux in view of Papayiannis in view of Teng teaches the method of claim 33, as referenced above. Devaux fails to teach wherein selecting the plurality of relevant APIs further comprises: determining, for each API of the plurality of APIs in an API catalog, a probability the API will provide at least a portion of the requested functionality of the payload request; and selecting APIs with probabilities above a threshold probability as relevant APIs.
However, Papayiannis teaches:
wherein selecting the plurality of relevant APIs further comprises: determining, for each API of the plurality of APIs in an API catalog, a (semantic similarity) probability the API will provide at least a portion of the requested functionality of the payload request; “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 or the current task, APIs that are capable of performing the current task, etc.) … compare (e.g., using cosine similarity) the encoded representation(s) to an encoded representation of an API description for the API to determine whether the API is semantically similar to the user input or the current task … If the value of semantic similarity meets or exceeds a threshold, the API (and, optionally, the API description) may be included in the relevant API data 635” [Papayiannis ¶ 103].
and selecting APIs with probabilities above a threshold (semantic similarity) probability as relevant APIs. “If the value of semantic similarity meets or exceeds a threshold, the API (and, optionally, the API description) may be included in the relevant API data 635” [Papayiannis ¶ 103].
Devaux in view of Papayiannis in view of Teng fails to explicitly teach probability.
However, Patil teaches probability “As a further example, consider an embodiment in which response generating machine learning algorithm 136c is a machine comprehension algorithm that is configured to identify content stored in database 110 that is responsive to text request 202, based on the semantic similarity between text request 202 and the content. Response generating algorithm 136c may provide, as output, (1) the content identified as responsive to text request 202, and (2) a probability that this content is responsive to text request 202, where the probability corresponds to the semantic similarity between text request 202 and the content identified as responsive to the request” [Patil ¶ 62].
The claimed invention is directed to a process which determines, for APIs in a catalog, a probability that each API will provide a requested functionality and selects APIs with probabilities above a threshold. The system of Papayiannis determines, for APIs in a catalog, a semantic similarity value that each API will provide a requested functionality and selects APIs with a semantic similarity value above a threshold. Papayiannis’s system differs from the claimed invention by using a semantic similarity value instead of a probability. The system of Patil teaches that a semantic similarity value corresponds to a probability of responding to a request. Thus, it would have been obvious to one of ordinary skill in the art to make a simple substitution of the prior art semantic similarity value with another known value of probability of responding to a request, because one of ordinary skill in the art would have been able to carry out such a substitution and the results were reasonably predicable in that a semantic similarity value can correspond to a probability of responding to a request, but would still allow for selection of an API and thus achieve the same functionality.
Claim(s) 37-40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Devaux et al. US 2024/0370505 A1 (hereafter Devaux) in view of Papayiannis et al. US 2025/0104693 A1 (hereafter Papayiannis) in view of Teng et al. US 2025/0131190 A1 (hereafter Teng) in view of Roy US 2023/0049550 A1 (hereafter Roy).
With regard to claim 37, Devaux teaches:
A method for generating a payload response providing a requested functionality, the method comprising: “Block 312 comprises defining structured response formats for unstructured queries. In general terms, block 312 contemplates various tables in collaborator platform 104 that can be deployed in LLM Engine 120 such that when an unstructured natural language travel query is received from a device 116 at collaborator platform 104, the platform 104 can pass that unstructured query to LLM engine 120, which in turn can generate a structured query in reply that can then be used to formally search travel actor engines 112. The results from the travel actor engines 112 can then be returned to the originating device 116” [Devaux ¶ 109]. “FIG. 28 is an illustrative representation showcasing the application of a formal API description in the generation of a chain of thought” [Devaux ¶ 74, fig. 28].
receiving, at a network system from a client device, a payload request comprising a natural language request for the requested functionality, “FIG. 28 illustrates the LLM's capacity to engage in a contextually adaptive dialogue, employing its reasoning capabilities to sequence API calls and data processing tasks in response to a user's natural language query” [Devaux ¶ 310, fig. 28]. “The one or more travel contexts from block 308 include tables that provide contextual shifts for LLM engine 120, that situate LLM engine 120 in the context of a travel assistant and establish how the LLM engine 120 is to manage and respond to natural language travel queries received at various client devices 116 on behalf of users 124, as those queries are received by collaborator platform 104 and passed along to LLM engine 120” [Devaux ¶ 103].
wherein the requested functionality is achievable using one or more APIs from an API catalog; “An aspect of the specification provides a search engine server wherein the request intention is planning a travel itinerary and the plurality of sources includes selecting the API and/or the database hosted by a subset of a plurality of online travel solution providers within the full domain of sources” [Devaux ¶ 16]. “FIG. 28 is an illustrative representation showcasing the application of a formal API description 2800 in the generation of a chain of thought by a Large Language Model (LLM), specifically using GPT. API description 2800 exemplifies how GPT-4 processes structured API data to logically construct a step-by-step solution that aligns with the methodological innovations of system 100b. FIG. 28 illustrates the LLM's capacity to engage in a contextually adaptive dialogue, employing its reasoning capabilities to sequence API calls and data processing tasks in response to a user's natural language query. The API description of FIG. 28 serves as a visualization of the advanced cognitive interactions between GPT-4 and various data sources within system 100b. FIG. 28 highlights the seamless integration of conversational AI with formal API endpoints in the generation of a chain of thought by a Large Language Model (LLM), specifically using GPT-4” [Devaux ¶ 310, fig. 28]. “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137].
identifying a set of executable APIs from the API catalog that, when executed, provide the requested functionality, “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137].
wherein the set of APIs is identified by: applying, at the network system, a small language model to the payload request to determine a set of relevant APIs in the API catalog that provide the requested functionality, wherein the set of relevant APIs are selected based on generated embeddings that map(ping) the natural language in the payload request to the functionality of the APIs in the API catalog; “Block 2508 comprises determining at least one parameter from a request intention within the conversational session” [Devaux ¶ 251]. “Block 2512 comprises determining a meta-description based on the parameters. This involves synthesizing a concise overview of the data related to the identified parameters, which serves to contextualize and streamline the selection process in subsequent steps” [Devaux ¶ 257]. “Block 2516 comprises selecting, based on the at least one parameter and the meta-description, a plurality of nodes representing sources within a full domain of sources. These sources may include, but are not limited to, a function call via an application programming interface (API), a database, and a large language model. The meta-description acts as a set of criteria that enables the system to understand and categorize the information required from different sources. The meta-description guides the actual search engine server (e.g. Travel management engine 122b) in identifying which nodes (e.g. Travel actor engines 112) are relevant for the search query, and what kind of information to retrieve from them” [Devaux ¶ 258-259]. “Identification of Data Sources: The meta-description can outline the types of data needed to satisfy the user's query. Based on the criteria specified in the meta-description, the search engine server determines which APIs (relevant APIs), databases, or language models have the potential to provide the required information. Matching Criteria with Capabilities: The search engine server compares the criteria from the meta-description to the capabilities of various data sources. This involves looking at the data fields that each API or database can supply and ensuring they align with the data fields outlined in the meta-description” [Devaux ¶ 260-261].
and applying, at the network system, a large language model to the payload request and the set of relevant APIs to determine the set of executable APIs that generates the requested functionality, “An aspect of the specification provides a search engine server wherein the meta-description is used by a large language model to select the plurality of nodes” [Devaux ¶ 10]. “A person skilled in the art can also appreciate how the structured queries generated by LLM engine 120 can be extremely sophisticated in nature, whereby travel management engine 122 may make a series of structured queries to travel actor engines 112” [Devaux ¶ 137]. “According to our illustrative example from FIG. 6, however, block 424 is reached from block 420, when the LLM Engine 120 determines that it has enough unstructured searching elements from message 504-1 and message 504-3 to prepare a fully structured travel query. Thus, according to our example in FIG. 6, block 424 comprises engaging LLM to prepare a draft response that also includes a structured travel query” [Devaux ¶ 126-127]. “Node Selection: Once potential data sources are identified, the search engine server selects nodes that match the meta-description most closely. For instance, if the meta description calls for detailed cultural information about Buddhist temples, the search engine server may select nodes like cultural heritage databases and local tourism APIs that provide such data. Similarly, if the meta-description refers to a conversation aiming at giving inspiration, the server may select nodes favoring exploration and diversity of content (search APIs) over nodes favoring sales and depth of content (booking APIs)” [Devaux ¶ 262]. “Node combination: Once the server has selected nodes or data sources, the server defines in which sequence and/or conditions to execute the queries on the selected nodes. For instance, queries on data sources providing information on Buddhist temples can be executed in parallel and the results can be grouped together. Moreover, the server may describe how the search results of a data source may be used, in conjunction with other elements in the meta description, to form the input of a subsequent query on another data source. For example, a subsequent call to the API of a local tourism board may be necessary to retrieve the dates of the occurrence of a yearly Buddhist festival” [Devaux ¶ 264].
the large language model interpreting context and intent of the payload request to select one or more relevant APIs for the set of executable APIs based on the context and intent; “FIG. 28 highlights the seamless integration of conversational AI with formal API endpoints in the generation of a chain of thought by a Large Language Model (LLM), specifically using GPT-4. API description 2800 can thus be used to configure LLM engine 120b as part of method 2500” [Devaux ¶ 310]. “Referring now to FIG. 29, a further variant on system 100, system 100a, and, system 100b is shown as system 100c … Search engine server 2900c accommodates conversations 1404c with users 124c via devices 116c. Conversations 1404c are processed using method 2500, creating one more query graphs 2904 at block 2528 during iterations through method 2500 throughout the course of conversation 1404c, eventually executing a query at block 2532. Such query graphs 2904 represent a chain of thought that can be used to efficiently effect intentions from conversation 1404c” [Devaux ¶ 320, fig. 29]. “The one or more travel contexts from block 308 include tables that provide contextual shifts for LLM engine 120, that situate LLM engine 120 in the context of a travel assistant and establish how the LLM engine 120 is to manage and respond to natural language travel queries received at various client devices 116 on behalf of users 124, as those queries are received by collaborator platform 104 and passed along to LLM engine 120” [Devaux ¶ 103]. “As a non-limiting illustrative example, interactions between a device 116, collaboration platform 104 and LLM engine 120 can result in natural language processing of messages, such as message 504-1, to ascertain an origin from an intent extracted from the message. Message 504-1 is a salient example, which includes the sentence "Hey, I need to book a Flight to Paris". Collaboration platform 104a and LLM engine 120a can thus derive the origin parameter "Paris" from message 504-1” [Devaux ¶ 145].
executing the single API to generate a payload response providing the requested functionality; Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265].
and responsive to the set of executable APIs comprising two or more APIs, executing the two or more APIs in a sequence to generate a payload response providing the requested functionality. “According to system 100c, a single search engine server 2900c is provided which can access LLM engine 120c and effect searches over engines 113c using method 2500. Search engine server 2900c accommodates conversations 1404c with users 124c via devices 116c. Conversations 1404c are processed using method 2500, creating one more query graphs 2904 at block 2528 during iterations through method 2500 throughout the course of conversation 1404c, eventually executing a query at block 2532. Such query graphs 2904 represent a chain of thought that can be used to efficiently effect intentions from conversation 1404c” [Devaux ¶ 320, fig. 29]. “A person skilled in the art can also appreciate how the structured queries generated by LLM engine 120 can be extremely sophisticated in nature, whereby travel management engine 122 may make a series of structured queries to travel actor engines 112. Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137]. “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265].
Devaux fails to explicitly teach wherein the set of APIs is identified by: applying, at the network system, a small language model to the payload request to determine a set of relevant APIs in the API catalog that provide the requested functionality, wherein the set of relevant APIs are selected based on generated embeddings that map the natural language in the payload request to the functionality of the APIs in the API catalog.
However, Papayiannis teaches:
wherein the set of APIs is identified by: applying, at the network system, a small language model to the payload request to determine a set of relevant APIs in the API catalog that provide the requested functionality, wherein the set of relevant APIs are selected based on generated (encodings) embeddings that map the natural language in the payload request to the functionality of the APIs in the API catalog; “The relevant API data 635 may be generated by the API shortlister component 620, which may be configured to retrieve one or more (e.g., top-k) relevant APIs associated with the user input data 102 or the current task” [Papayiannis ¶ 102]. “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 or the current task, APIs that are capable of performing the current task, etc.). In some embodiments, the API shortlister component 620 (or another component of the API shortlister component 620) may determine an encoded representation of the user input or the current task and compare (e.g., using cosine similarity) the encoded representation(s) to an encoded representation of an API description for the API to determine whether the API is semantically similar to the user input or the current task” [Papayiannis ¶ 103]. “The user input data 102 may be received at the encoder component 940 of the arbitrator component 882. The encoder component 940 may process the user input data 102 to generate encoded user input data 945 represented an encoded representation of the user input data 102 (e.g., a vectorized representation of the user input)” [Papayiannis ¶ 167].
Papayiannis is considered to be analogous to the claimed invention because it is in the same field of machine learning. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux to incorporate the teachings of Papayiannis and include wherein the set of APIs is identified by: applying, at the network system, a small language model to the payload request to determine a set of relevant APIs in the API catalog that provide the requested functionality, wherein the set of relevant APIs are selected based on generated (encodings) embeddings that map the natural language in the payload request to the functionality of the APIs in the API catalog. Doing so would allow for only APIs within a threshold level of similarity to be considered relevant. “If the value of semantic similarity meets or exceeds a threshold, the API (and, optionally, the API description) may be included in the relevant API data 635” [Papayiannis ¶ 103].
Devaux in view of Papayiannis fails to teach applying, at the network system, a small language model to the payload request to determine a set of relevant APIs in the API catalog that provide the requested functionality, wherein the set of relevant APIs are selected based on generated embeddings that map the natural language in the payload request to the functionality.
However, Teng teaches applying, at the network system, a small language model to the payload request to determine a set of relevant APIs in the API catalog that provide the requested functionality, wherein the set of relevant APIs are selected based on generated embeddings that map the natural language in the payload request to the functionality “The lightweight profile summary model 234 may be a lightweight language model or a specialized machine learning model designed to process and transform raw contextual data into a language or format that can be easily interpreted by other systems, such as LXMs. The "lightweight" characteristic signifies a smaller size and fewer parameters (e.g., hundreds of thousands to tens of millions of parameters, dozens to a few hundred tokens, etc.), enabling faster processing and reduced computational demands” [Teng ¶ 72]. “The term "embedding layer" is used herein to refer to a specialized layer within a neural network, typically at the input stage, that transforms continuous or discrete categorical values or tokens into continuous, high-dimensional vectors. An embedding layer may also transform high-dimensional data into low-dimensional vectors (e.g., using "dimensionality reduction" techniques, etc.), which may be particularly useful when the original data is complex or too large to handle efficiently. For lightweight language models, the embedding layer may convert tokens (typically low-dimensional entities) into high-dimensional vectors. An embedding layer may operate as a lookup table in which each unique token or category is mapped to a point in a continuous vector space. The vectors may be refined during the model's training phase to encapsulate the characteristics or attributes of the tokens in a manner that is conducive to the tasks the model is configured to perform. The term "token" is used herein to refer to a unit of information that an LXM may read as a single input during training and inference. Each token may represent any of a variety of different data types. For example, in text-centric models such as in LLMs, each token may represent a one or more textual element such as a paragraph(s), sentence(s), clause(s), word(s), sub-word(s), character(s), etc” [Teng ¶ 44-45].
Teng is considered to be analogous to the claimed invention because it is in the same field of machine learning. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux in view of Papayiannis to incorporate the teachings of Teng and include applying, at the network system, a small language model to the payload request to determine a set of relevant APIs in the API catalog that provide the requested functionality, wherein the set of relevant APIs are selected based on generated embeddings that map the natural language in the payload request to the functionality. Doing so would allow for further optimization and efficiency. “Lightweight language models may be trained or optimized for specific tasks for which privacy or computational efficiency is a priority. The lightweight nature allows for quicker deployment and reduced latency during the inference stage, making them suitable for real-time applications or environments with limited computational resources … In some embodiments, lightweight language models may operate in tandem with more resource-intensive models, offloading certain tasks to optimize overall system performance” [Teng ¶ 36].
Devaux in view of Papayiannis in view of Teng fails to explicitly teach responsive to the set of executable APIs comprising a single API, executing the single API to generate a payload response providing the requested functionality.
responsive to the set of executable APIs comprising a single API, executing (selecting) the single API to generate a payload response providing the requested functionality; “In one example, for the AI-Bot 620 to satisfy the intent of the user 610, the AI-Bot 620 communicates with many disparate functional entities that have registered their individual APIs in a global API registry for selection of an appropriate API with specific declarative parameters to satisfy a goal (Part VI). This can produce an objective of mapping a natural language user expression into a concreate API call” [Roy ¶ 153-154]. “FIG. 7 illustrates one embodiment of an example cybersecurity application environment 700. The environment 700 can be employed to find a specific API whose functions will satisfy a user's command” [Roy ¶ 155]. “The API declaration selector component 740 can apply expressivity (e.g., in the form of declaration) upon individual APIs of the candidate APIs. This matches the individual APIs with inputted user expressions. In one example, this is accomplished by leveraging the ML/DL features of the word embedding component 710A to select a best matching API as the candidate declaration set and associated API, which can be transferred to the entity parameter mapper component 750” [Roy ¶ 160]. “The converge checker component 760 can chose a best match declaration, such as one with a maximum number of parameters fulfilled amongst candidate API declarations before an API call is generated by the API call generation component 770” [Roy ¶ 162].
Roy is considered to be analogous to the claimed invention because it is in the same field of machine learning. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Devaux in view of Papayiannis in view of Teng to incorporate the teachings of Roy and include responsive to the set of executable APIs comprising a single API, executing (selecting) the single API to generate a payload response providing the requested functionality. Doing so would allow for a request to be fulfilled using a singular API. “This can produce an objective of mapping a natural language user expression into a concreate API call. A lot of complexities can be involved to resolve a command of the user 620 when using NLP and the API can be a beneficial solution to retrieve an appropriate function” [Roy ¶ 154].
With regard to claim 38, Devaux in view of Papayiannis in view of Teng in view of Roy teaches the method of claim 37, as referenced above. Devaux further teaches:
wherein set of executable APIs comprises two or more APIs, “Node combination: Once the server has selected nodes or data sources, the server defines in which sequence and/or conditions to execute the queries on the selected nodes. For instance, queries on data sources providing information on Buddhist temples can be executed in parallel and the results can be grouped together. Moreover, the server may describe how the search results of a data source may be used, in conjunction with other elements in the meta-description, to form the input of a subsequent query on another data source. For example, a subsequent call to the API of a local tourism board may be necessary to retrieve the dates of the occurrence of a yearly Buddhist festival” [Devaux ¶ 264]. “According to system 100c, a single search engine server 2900c is provided which can access LLM engine 120c and effect searches over engines 113c using method 2500. Search engine server 2900c accommodates conversations 1404c with users 124c via devices 116c. Conversations 1404c are processed using method 2500, creating one more query graphs 2904 at block 2528 during iterations through method 2500 throughout the course of conversation 1404c, eventually executing a query at block 2532. Such query graphs 2904 represent a chain of thought that can be used to efficiently effect intentions from conversation 1404c” [Devaux ¶ 320, fig. 29 Examiner notes query graph 2904 of multiple APIs in figure 29]. “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta description's specifications” [Devaux ¶ 265].
and executing the APIs in a sequence comprises: identifying, from the set of executable APIs, a next sequenced API for an API chain, the next sequenced API configured to provide partial functionality. “Node combination: Once the server has selected nodes or data sources, the server defines in which sequence and/or conditions to execute the queries on the selected nodes. For instance, queries on data sources providing information on Buddhist temples can be executed in parallel and the results can be grouped together. Moreover, the server may describe how the search results of a data source may be used, in conjunction with other elements in the meta description, to form the input of a subsequent query on another data source. For example, a subsequent call to the API of a local tourism board may be necessary to retrieve the dates of the occurrence of a yearly Buddhist festival” [Devaux ¶ 264]. “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137].
With regard to claim 39, Devaux in view of Papayiannis in view of Teng in view of Roy teaches the method of claim 38, as referenced above. Devaux further teaches:
wherein executing the two or more APIs in a sequence comprises: while an output of an execution of the API chain is a partial functionality different from the requested functionality: executing the next sequenced API to generate the output for the API chain; “According to system 100c, a single search engine server 2900c is provided which can access LLM engine 120c and effect searches over engines 113c using method 2500. Search engine server 2900c accommodates conversations 1404c with users 124c via devices 116c. Conversations 1404c are processed using method 2500, creating one more query graphs 2904 at block 2528 during iterations through method 2500 throughout the course of conversation 1404c, eventually executing a query at block 2532. Such query graphs 2904 represent a chain of thought that can be used to efficiently effect intentions from conversation 1404c” [Devaux ¶ 320, fig. 29 Examiner notes query graph 2904 of multiple APIs in figure 29]. “Node combination: Once the server has selected nodes or data sources, the server defines in which sequence and/or conditions to execute the queries on the selected nodes. For instance, queries on data sources providing information on Buddhist temples can be executed in parallel and the results can be grouped together. Moreover, the server may describe how the search results of a data source may be used, in conjunction with other elements in the meta-description, to form the input of a subsequent query on another data source. For example, a subsequent call to the API of a local tourism board may be necessary to retrieve the dates of the occurrence of a yearly Buddhist festival” [Devaux ¶ 264].
responsive to determining the output for the API chain is the partial functionality, selecting and executing an additional API from the set of executable APIs as the next sequenced API in the API chain, wherein: the next sequenced API is configured to provide the requested functionality based on the partial functionality, “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137].
and the next sequenced API is selected by the large language model by comparing the partial functionality to the requested functionality based on embeddings for the selected next sequenced API and the additional API; “An aspect of the specification provides a search engine server wherein the meta-description is used by a large language model to select the plurality of nodes” [Devaux ¶ 10]. “A person skilled in the art can also appreciate how the structured queries generated by LLM engine 120 can be extremely sophisticated in nature, whereby travel management engine 122 may make a series of structured queries to travel actor engines 112” [Devaux ¶ 137]. “Node Selection: Once potential data sources are identified, the search engine server selects nodes that match the meta-description most closely. For instance, if the meta-description calls for detailed cultural information about Buddhist temples, the search engine server may select nodes like cultural heritage databases and local tourism APIs that provide such data. Similarly, if the meta-description refers to a conversation aiming at giving inspiration, the server may select nodes favoring exploration and diversity of content (search APIs) over nodes favoring sales and depth of content (booking APIs)” [Devaux ¶ 261].
and responsive to determining the output for the API chain is the requested functionality, generating the payload response comprising the requested functionality resulting from the API chain. “Query Execution: With the query parameters set, the search engine server executes the queries on the selected nodes. It sends out requests over the network to the chosen APIs and databases, which return data matching the meta-description's specifications. Data Aggregation and Refinement: The search engine server collects the responses from the various nodes, aggregates the data, and refines it based on the meta-description. This ensures that only relevant and useful information is included in the final response to the user's query” [Devaux ¶ 265-266].
Devaux in view of Papayiannis fails to explicitly teach based on embeddings.
However, Teng teaches based on embeddings “The term "embedding layer" is used herein to refer to a specialized layer within a neural network, typically at the input stage, that transforms continuous or discrete categorical values or tokens into continuous, high-dimensional vectors. … An embedding layer may operate as a lookup table in which each unique token or category is mapped to a point in a continuous vector space. The vectors may be refined during the model's training phase to encapsulate the characteristics or attributes of the tokens in a manner that is conducive to the tasks the model is configured to perform” [Teng ¶ 44].
With regard to claim 40, Devaux in view of Papayiannis in view of Teng in view of Roy teaches the method of claim 37, as referenced above. Devaux further teaches:
wherein executing the two or more APIs in a sequence comprises generating an ordered sequence of executable APIs from the set of executable API, and wherein generating the ordered sequence of executable APIs comprises: determining a partial functionality provided by each of the relevant APIs when executed; “According to system 100c, a single search engine server 2900c is provided which can access LLM engine 120c and effect searches over engines 113c using method 2500. Search engine server 2900c accommodates conversations 1404c with users 124c via devices 116c. Conversations 1404c are processed using method 2500, creating one more query graphs 2904 at block 2528 during iterations through method 2500 throughout the course of conversation 1404c, eventually executing a query at block 2532. Such query graphs 2904 represent a chain of thought that can be used to efficiently effect intentions from conversation 1404c” [Devaux ¶ 320, fig. 29 Examiner notes query graph 2904 of multiple APIs in figure 29]. “Node combination: Once the server has selected nodes or data sources, the server defines in which sequence and/or conditions to execute the queries on the selected nodes. For instance, queries on data sources providing information on Buddhist temples can be executed in parallel and the results can be grouped together. Moreover, the server may describe how the search results of a data source may be used, in conjunction with other elements in the meta-description, to form the input of a subsequent query on another data source. For example, a subsequent call to the API of a local tourism board may be necessary to retrieve the dates of the occurrence of a yearly Buddhist festival” [Devaux ¶ 264]. “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137].
and determining an API order for the ordered sequence based on the partial functionality of each of the relevant APIs, the order causing the requested functionality to be achieved when the partial functionalities are performed in the order. “Here is an example scenario. If user 124-1 generates an unstructured natural language query of the form "I would like to see flights from Nice to Paris on April 12 where the flights must land only during operational hours of the Paris Metro system", then a first structured query can be made of a first travel actor engine 112 that has information about the operational hours of the Paris Metro system, which can then be returned to LLM engine 120 to generate a second structured query that filters by flights that land during the operational hours returned from the first query” [Devaux ¶ 137].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at (571) 272-3338. 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.
/A.F.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
