DETAILED ACTION
Claims 1-20 are pending in this application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2025/0021767 A1 to Dharnidharka et al. in view of U.S. Pub. No. 2025/0045025 A1 to Chakhvadze et al.
As to claim 1, Dharnidharka teaches a method for processing a query using a machine-trained language model, comprising:
receiving the query (user input such as a natural language description of a search query) (“… As will be discussed in further detail below, the model training system 170 is configured to receive user input such as a natural language description of a search query, which is provided as a prompt to a plurality of large learning models (LLMs) by the model training system 170. In some implementations, the model training system 170 may generate a graphical user interface (GUI) that includes a user interface element (UI element) configured to, upon activation by user input, “fetch” a natural language description of a search query. The fetch operation may refer to retrieving a predetermined natural language description of a search query from a data store, which may be included as part of the storage 164 or may be a separate non-transitory, computer-readable medium storage component (not shown). In other embodiments, the fetch operation may refer to transmission of a prompt to a LLM requesting a natural language description of a search query, receipt of the response from the LLM, and provision of the result to the user via the graphical user interface and/or be packaged as a prompt for a plurality of LLMs…The model training system 170 includes logic configured to receive the natural language description, package the natural language description as a prompt to a plurality of LLMs at least by determining an API for each of the plurality of LLMs and arranging data to be provided to each of the plurality of LLMs according to the corresponding API. In some examples, the necessary API information and detail is stored in the model and API storage 171. The packaged natural language search queries are then transmitted to the plurality of LLMs and the responses are received. The responses may then be anonymized and displayed to the user for user assessment via the GUI. The GUI may also be configured to receive user feedback corresponding to indications as to whether each response is correct, syntactically and/or semantically, and, in some examples, an indication of which response was preferred. In some examples, the user feedback may include a ranking of the level of correctness and/or the user preference of the responses…” paragraphs 0024/0025);
generating a first prompt (prompt) that includes a description of the query and selector information, the selector information including an instruction to select one or more functions from a group of functions, and a summary of the functions in the group of functions (determining an API) (“… As will be discussed in further detail below, the model training system 170 is configured to receive user input such as a natural language description of a search query, which is provided as a prompt to a plurality of large learning models (LLMs) by the model training system 170. In some implementations, the model training system 170 may generate a graphical user interface (GUI) that includes a user interface element (UI element) configured to, upon activation by user input, “fetch” a natural language description of a search query. The fetch operation may refer to retrieving a predetermined natural language description of a search query from a data store, which may be included as part of the storage 164 or may be a separate non-transitory, computer-readable medium storage component (not shown). In other embodiments, the fetch operation may refer to transmission of a prompt to a LLM requesting a natural language description of a search query, receipt of the response from the LLM, and provision of the result to the user via the graphical user interface and/or be packaged as a prompt for a plurality of LLMs…The model training system 170 includes logic configured to receive the natural language description, package the natural language description as a prompt to a plurality of LLMs at least by determining an API for each of the plurality of LLMs and arranging data to be provided to each of the plurality of LLMs according to the corresponding API. In some examples, the necessary API information and detail is stored in the model and API storage 171. The packaged natural language search queries are then transmitted to the plurality of LLMs and the responses are received. The responses may then be anonymized and displayed to the user for user assessment via the GUI. The GUI may also be configured to receive user feedback corresponding to indications as to whether each response is correct, syntactically and/or semantically, and, in some examples, an indication of which response was preferred. In some examples, the user feedback may include a ranking of the level of correctness and/or the user preference of the responses…” paragraphs 0024/0025);
sending the first prompt to the machine-trained language model (plurality of large learning models (LLMs)) (“… As will be discussed in further detail below, the model training system 170 is configured to receive user input such as a natural language description of a search query, which is provided as a prompt to a plurality of large learning models (LLMs) by the model training system 170. In some implementations, the model training system 170 may generate a graphical user interface (GUI) that includes a user interface element (UI element) configured to, upon activation by user input, “fetch” a natural language description of a search query. The fetch operation may refer to retrieving a predetermined natural language description of a search query from a data store, which may be included as part of the storage 164 or may be a separate non-transitory, computer-readable medium storage component (not shown). In other embodiments, the fetch operation may refer to transmission of a prompt to a LLM requesting a natural language description of a search query, receipt of the response from the LLM, and provision of the result to the user via the graphical user interface and/or be packaged as a prompt for a plurality of LLMs…The model training system 170 includes logic configured to receive the natural language description, package the natural language description as a prompt to a plurality of LLMs at least by determining an API for each of the plurality of LLMs and arranging data to be provided to each of the plurality of LLMs according to the corresponding API. In some examples, the necessary API information and detail is stored in the model and API storage 171. The packaged natural language search queries are then transmitted to the plurality of LLMs and the responses are received. The responses may then be anonymized and displayed to the user for user assessment via the GUI. The GUI may also be configured to receive user feedback corresponding to indications as to whether each response is correct, syntactically and/or semantically, and, in some examples, an indication of which response was preferred. In some examples, the user feedback may include a ranking of the level of correctness and/or the user preference of the responses…” paragraphs 0024/0025); and
receiving a first language-model response from the machine-trained language model that the machine-trained language model generates in response to the first prompt, the first language-model response including identification information that identifies a particular function specified in the group of functions (receipt of the response from the LLM, and provision of the result to the user via the graphical user interface and/or be packaged as a prompt for a plurality of LLMs) (“… As will be discussed in further detail below, the model training system 170 is configured to receive user input such as a natural language description of a search query, which is provided as a prompt to a plurality of large learning models (LLMs) by the model training system 170. In some implementations, the model training system 170 may generate a graphical user interface (GUI) that includes a user interface element (UI element) configured to, upon activation by user input, “fetch” a natural language description of a search query. The fetch operation may refer to retrieving a predetermined natural language description of a search query from a data store, which may be included as part of the storage 164 or may be a separate non-transitory, computer-readable medium storage component (not shown). In other embodiments, the fetch operation may refer to transmission of a prompt to a LLM requesting a natural language description of a search query, receipt of the response from the LLM, and provision of the result to the user via the graphical user interface and/or be packaged as a prompt for a plurality of LLMs…The model training system 170 includes logic configured to receive the natural language description, package the natural language description as a prompt to a plurality of LLMs at least by determining an API for each of the plurality of LLMs and arranging data to be provided to each of the plurality of LLMs according to the corresponding API. In some examples, the necessary API information and detail is stored in the model and API storage 171. The packaged natural language search queries are then transmitted to the plurality of LLMs and the responses are received. The responses may then be anonymized and displayed to the user for user assessment via the GUI. The GUI may also be configured to receive user feedback corresponding to indications as to whether each response is correct, syntactically and/or semantically, and, in some examples, an indication of which response was preferred. In some examples, the user feedback may include a ranking of the level of correctness and/or the user preference of the responses…” paragraphs 0024/0025).
Dharnidharka is silent with reference to generating a second prompt that provides a particular instance of function definition information that describes the particular function in more detail than the selector information in the first prompt by specifying at least input information to be provided to the particular function, the second prompt having fewer tokens than an amount of tokens that would be needed to describe all of the functions in the group of functions;
sending the second prompt to the machine-trained language model;
receiving a second language-model response that the machine-trained language model generates in response to the second prompt, the second language-model response providing invocation information for invoking the particular function with input information that is formatted in a manner specified by the particular instance of function definition information; and
invoking the particular function specified by the invocation information.
Chakhvadze teaches generating a second prompt that provides a particular instance of function definition information that describes the particular function in more detail than the selector information in the first prompt by specifying at least input information to be provided to the particular function (the data management system generates a further prompt (e.g., the second prompt)) (“…In various embodiments, the data management system automatically handles error detection and correction based on model responses. Specifically, upon receiving a model response, the data management system determines if an error occurred during at least one of the operations, including the operation of parsing the response; the operation of validating the parsed response, and the operation of generating the one or more programming data objects in the requested machine-readable format. Once an error is detected, the data management system generates a further prompt (e.g., the second prompt) based on a text description of the error and the model response that includes the error. The data management system uses the machine learning model to generate a further model response (e.g., second response) in the output format (e.g., requested machine-readable format) based on the further prompt. Once the further model response is generated, the data management system parses the response, validates the response against the schema, and converts the response into one or more into one or more programming data objects in the requested machine-readable format. Upon determining the further model response is free from error, the data management system passes the one or more programming data objects as function outputs to the requesting user for downstream processing…” paragraph 0020), the second prompt having fewer tokens than an amount of tokens that would be needed to describe all of the functions in the group of functions (the token budget of each data chunk is dynamically calculated based on the current size of the internal state parameter, so that the number of tokens in the resulting prompt is not larger than the maximum number of tokens supported by the large language model) (“…At operation 608, the processor dynamically calculates a token budget based on an internal state parameter. The internal state parameter is updated before the processor identifies and process a next data chunk. As more data chunks are identified and processed, the size of the internal state parameter continues to grow. Given that the total length of model input and output is limited, the token budget of each data chunk is dynamically calculated based on the current size of the internal state parameter, so that the number of tokens in the resulting prompt is not larger than the maximum number of tokens supported by the large language model…” paragraph 0082),
sending the second prompt to the machine-trained language model/
receiving a second language-model response that the machine-trained language model generates in response to the second prompt, the second language-model response providing invocation information for invoking the particular function with input information that is formatted in a manner specified by the particular instance of function definition information (The data management system uses the machine learning model to generate a further model response (e.g., second response) in the output format (e.g., requested machine-readable format) based on the further prompt) (“…In various embodiments, calling a function can include specifying the function name, function definitions, function call operator, and data values (also referred to as arguments) the function expects to receive. Arguments are values for the parameters defined for the function. Arguments can be passed to the function provided by the data management system…In various embodiments, the data management system automatically handles error detection and correction based on model responses. Specifically, upon receiving a model response, the data management system determines if an error occurred during at least one of the operations, including the operation of parsing the response; the operation of validating the parsed response, and the operation of generating the one or more programming data objects in the requested machine-readable format. Once an error is detected, the data management system generates a further prompt (e.g., the second prompt) based on a text description of the error and the model response that includes the error. The data management system uses the machine learning model to generate a further model response (e.g., second response) in the output format (e.g., requested machine-readable format) based on the further prompt. Once the further model response is generated, the data management system parses the response, validates the response against the schema, and converts the response into one or more into one or more programming data objects in the requested machine-readable format. Upon determining the further model response is free from error, the data management system passes the one or more programming data objects as function outputs to the requesting user for downstream processing…At operation 606, the processor processes the collection of data units to generate a plurality of outputs. The processing of the collection can include a number of operations, such as operations 608 through 614. In various embodiments, data management system can provide one or more functions that can be called to handles the processing of the collection of data units. For example, inputs to a function that is provided to processing of the collection of data units can include instruction prompt template, zero or more arguments (also referred to as function parameters, or parameters) passed as symbolic chunk iterators, and zero or more arguments representing internal state parameter. Example outputs of such a function can include a final results that includes aggregated (or merged) outputs resulting from the processing of the collection…” paragraphs 0018/0020/0081), and
invoking the particular function specified by the invocation information (“…In various embodiments, calling a function can include specifying the function name, function definitions, function call operator, and data values (also referred to as arguments) the function expects to receive. Arguments are values for the parameters defined for the function. Arguments can be passed to the function provided by the data management system…The API server 110 receives and transmits data (e.g., API calls, commands, requests, responses, and authentication data) between the client device 102 and the application server 116. Specifically, the API server 110 provides a set of interfaces (e.g., routines and protocols) that can be called or queried by the client software application 104 in order to invoke the functionality of the application server 116. The API server 110 exposes various functions supported by the application server 116 including, without limitation: user registration; login functionality; data object operations (e.g., generating, storing, retrieving, encrypting, decrypting, transferring, access rights, licensing, etc.); and user communications…” paragraph 0046).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Dharnidharka with the teaching of Chakhvadze because the teaching of Chakhvadze would improve the system of Dharnidharka by providing a token budget determining component for dynamically calculating token budget based on an internal state (also referred to as an internal state parameter) and corresponding to a number of tokens that exceeds an upper limit of tokens (e.g., the token budget) that a large language model can process (Chakhvadze paragraph 0056).
As to claim 15, Dharnidharka teaches a computing system for processing a query using a machine-trained language model, comprising:
an instruction data store for storing computer-readable instructions (Storage 124); and
a processing system for executing the computer-readable instructions in the data store (Processors 122), to perform operations including:
receiving the query (user input such as a natural language description of a search query) (“… As will be discussed in further detail below, the model training system 170 is configured to receive user input such as a natural language description of a search query, which is provided as a prompt to a plurality of large learning models (LLMs) by the model training system 170. In some implementations, the model training system 170 may generate a graphical user interface (GUI) that includes a user interface element (UI element) configured to, upon activation by user input, “fetch” a natural language description of a search query. The fetch operation may refer to retrieving a predetermined natural language description of a search query from a data store, which may be included as part of the storage 164 or may be a separate non-transitory, computer-readable medium storage component (not shown). In other embodiments, the fetch operation may refer to transmission of a prompt to a LLM requesting a natural language description of a search query, receipt of the response from the LLM, and provision of the result to the user via the graphical user interface and/or be packaged as a prompt for a plurality of LLMs…The model training system 170 includes logic configured to receive the natural language description, package the natural language description as a prompt to a plurality of LLMs at least by determining an API for each of the plurality of LLMs and arranging data to be provided to each of the plurality of LLMs according to the corresponding API. In some examples, the necessary API information and detail is stored in the model and API storage 171. The packaged natural language search queries are then transmitted to the plurality of LLMs and the responses are received. The responses may then be anonymized and displayed to the user for user assessment via the GUI. The GUI may also be configured to receive user feedback corresponding to indications as to whether each response is correct, syntactically and/or semantically, and, in some examples, an indication of which response was preferred. In some examples, the user feedback may include a ranking of the level of correctness and/or the user preference of the responses…” paragraphs 0024/0025);
in a first prompting operation, asking the machine-trained model to select a particular application programming interface (API) to be called in responding to the query, from a group of APIs (determining an API) (“… As will be discussed in further detail below, the model training system 170 is configured to receive user input such as a natural language description of a search query, which is provided as a prompt to a plurality of large learning models (LLMs) by the model training system 170. In some implementations, the model training system 170 may generate a graphical user interface (GUI) that includes a user interface element (UI element) configured to, upon activation by user input, “fetch” a natural language description of a search query. The fetch operation may refer to retrieving a predetermined natural language description of a search query from a data store, which may be included as part of the storage 164 or may be a separate non-transitory, computer-readable medium storage component (not shown). In other embodiments, the fetch operation may refer to transmission of a prompt to a LLM requesting a natural language description of a search query, receipt of the response from the LLM, and provision of the result to the user via the graphical user interface and/or be packaged as a prompt for a plurality of LLMs…The model training system 170 includes logic configured to receive the natural language description, package the natural language description as a prompt to a plurality of LLMs at least by determining an API for each of the plurality of LLMs and arranging data to be provided to each of the plurality of LLMs according to the corresponding API. In some examples, the necessary API information and detail is stored in the model and API storage 171. The packaged natural language search queries are then transmitted to the plurality of LLMs and the responses are received. The responses may then be anonymized and displayed to the user for user assessment via the GUI. The GUI may also be configured to receive user feedback corresponding to indications as to whether each response is correct, syntactically and/or semantically, and, in some examples, an indication of which response was preferred. In some examples, the user feedback may include a ranking of the level of correctness and/or the user preference of the responses…” paragraphs 0024/0025); and
receiving a first language-model response from the machine-trained language model that provides identification information that identifies the particular API in the group of APIs that is selected (receipt of the response from the LLM, and provision of the result to the user via the graphical user interface and/or be packaged as a prompt for a plurality of LLMs) (“… As will be discussed in further detail below, the model training system 170 is configured to receive user input such as a natural language description of a search query, which is provided as a prompt to a plurality of large learning models (LLMs) by the model training system 170. In some implementations, the model training system 170 may generate a graphical user interface (GUI) that includes a user interface element (UI element) configured to, upon activation by user input, “fetch” a natural language description of a search query. The fetch operation may refer to retrieving a predetermined natural language description of a search query from a data store, which may be included as part of the storage 164 or may be a separate non-transitory, computer-readable medium storage component (not shown). In other embodiments, the fetch operation may refer to transmission of a prompt to a LLM requesting a natural language description of a search query, receipt of the response from the LLM, and provision of the result to the user via the graphical user interface and/or be packaged as a prompt for a plurality of LLMs…The model training system 170 includes logic configured to receive the natural language description, package the natural language description as a prompt to a plurality of LLMs at least by determining an API for each of the plurality of LLMs and arranging data to be provided to each of the plurality of LLMs according to the corresponding API. In some examples, the necessary API information and detail is stored in the model and API storage 171. The packaged natural language search queries are then transmitted to the plurality of LLMs and the responses are received. The responses may then be anonymized and displayed to the user for user assessment via the GUI. The GUI may also be configured to receive user feedback corresponding to indications as to whether each response is correct, syntactically and/or semantically, and, in some examples, an indication of which response was preferred. In some examples, the user feedback may include a ranking of the level of correctness and/or the user preference of the responses…” paragraphs 0024/0025).
Dharnidharka is silent with reference to in a second prompting operation, asking the machine-trained language model to generate an API message to be input to the particular API that conforms to a particular instance of function definition information that describes the particular API, the second prompting operation producing fewer tokens than an amount of tokens that would be needed to describe all of the APIs in the group of APIs,
receiving a second language-model response that includes the API message that is generated, to be input to the particular API, and
sending the API message to the particular API to invoke the particular API.
Chakhvadze teaches in a second prompting operation, asking the machine-trained language model to generate an API message to be input to the particular API that conforms to a particular instance of function definition information that describes the particular API (the data management system generates a further prompt (e.g., the second prompt)) (“…In various embodiments, the data management system automatically handles error detection and correction based on model responses. Specifically, upon receiving a model response, the data management system determines if an error occurred during at least one of the operations, including the operation of parsing the response; the operation of validating the parsed response, and the operation of generating the one or more programming data objects in the requested machine-readable format. Once an error is detected, the data management system generates a further prompt (e.g., the second prompt) based on a text description of the error and the model response that includes the error. The data management system uses the machine learning model to generate a further model response (e.g., second response) in the output format (e.g., requested machine-readable format) based on the further prompt. Once the further model response is generated, the data management system parses the response, validates the response against the schema, and converts the response into one or more into one or more programming data objects in the requested machine-readable format. Upon determining the further model response is free from error, the data management system passes the one or more programming data objects as function outputs to the requesting user for downstream processing…” paragraph 0020),
the second prompting operation producing fewer tokens than an amount of tokens that would be needed to describe all of the APIs in the group of APIs (the token budget of each data chunk is dynamically calculated based on the current size of the internal state parameter, so that the number of tokens in the resulting prompt is not larger than the maximum number of tokens supported by the large language model) (“…At operation 608, the processor dynamically calculates a token budget based on an internal state parameter. The internal state parameter is updated before the processor identifies and process a next data chunk. As more data chunks are identified and processed, the size of the internal state parameter continues to grow. Given that the total length of model input and output is limited, the token budget of each data chunk is dynamically calculated based on the current size of the internal state parameter, so that the number of tokens in the resulting prompt is not larger than the maximum number of tokens supported by the large language model…” paragraph 0082),
receiving a second language-model response that includes the API message that is generated, to be input to the particular API, and
sending the API message to the particular API to invoke the particular API (“…In various embodiments, calling a function can include specifying the function name, function definitions, function call operator, and data values (also referred to as arguments) the function expects to receive. Arguments are values for the parameters defined for the function. Arguments can be passed to the function provided by the data management system…The API server 110 receives and transmits data (e.g., API calls, commands, requests, responses, and authentication data) between the client device 102 and the application server 116. Specifically, the API server 110 provides a set of interfaces (e.g., routines and protocols) that can be called or queried by the client software application 104 in order to invoke the functionality of the application server 116. The API server 110 exposes various functions supported by the application server 116 including, without limitation: user registration; login functionality; data object operations (e.g., generating, storing, retrieving, encrypting, decrypting, transferring, access rights, licensing, etc.); and user communications…” paragraph 0046).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Dharnidharka with the teaching of Dharnidharka because the teaching of Chakhvadze would improve the system of Kachuee by providing a token budget determining component for dynamically calculating token budget based on an internal state (also referred to as an internal state parameter) and corresponding to a number of tokens that exceeds an upper limit of tokens (e.g., the token budget) that a large language model can process (Chakhvadze paragraph 0056).
As to claim 20, see the rejection of claim 1, expect for a computer-readable storage medium.
Dharnidharka teaches a computer-readable storage medium (Storage 124).
Claims 1-4, 6, 14, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 12,626,698 A1 issued to Kachuee et al. in view of U.S. Pub. No. 2025/0045025 A1 to Chakhvadze et al.
As to claim 1, Kachuee teaches a method for processing a query using a machine-trained language model, comprising:
receiving the query (input/Request 104/User Input Data 227) (“…The input to the LLM may be in the form of a prompt. A prompt may be a natural language input, for example, an instruction, for the LLM to generate an output according to the prompt. The output generated by the LLM may be a natural language output responsive to the prompt. In some embodiments, the output may be another type of data, such as audio, image, video, etc. The prompt, in some cases, can also include in-context learning information that may be used by the LLM to generate a response to the prompt…FIG. 1A illustrates the component shortlister 102, according to various embodiments of the present disclosure. As shown in FIG. 1A, the component shortlister 102 takes as input a request 104 that may be a request to perform a task. In some cases, the request 104 may be a request that is to be provided to a LLM for processing. The component shortlister 102 may also optionally take as input a namespace 106, to focus shortlisting to components within the namespace, and/or max entries 108 to control the number of components 112 the component shortlister 102 outputs. As used herein, a “namespace” refers to a grouping of components based on topic/subject matter. Example namespaces includes, but are not limited to, music, smart home, weather, food ordering, ride sharing, travel, and video…In some embodiments, the LLM orchestrator component 130 may generate prompt data representing a prompt for input to the language models. As shown in FIG. 2, the system component(s) 220 receive user input data 227, which may be provided to the LLM orchestrator component 130. In some instances, the user input data 227 may correspond to various data types, such as text (e.g., a text or tokenized representation of a user input), audio, image, video etc. For example, the user input data may include input text (or tokenized) data when the user input is a typed natural language user input. For further example, prior to the LLM orchestrator component 130 receiving the user input data 227, another component (e.g., an automatic speech recognition (ASR) component 650) of the system 200 may receive audio data representing the user input. The ASR component 650 may perform ASR processing on the audio data to determine ASR data corresponding to the user input, which may correspond to a transcript of the user input. As described below, with respect to FIG. 6, the ASR component 650 may determine ASR data that includes an ASR N-best list including multiple ASR hypotheses and corresponding confidence scores representing what the user may have said. The ASR hypotheses may include text data, token data, ASR confidence score, etc. as representing the input utterance. The confidence score of each ASR hypothesis may indicate a level of confidence of the ASR component 650 that the corresponding hypothesis represents what the user said. The ASR component 650 may also determine token scores corresponding to each token/word of the ASR hypothesis, where the token score indicates the level of confidence of the ASR component 650 that the respective token/word was spoken by the user. The token scores may be identified as an entity score when the corresponding token relates to an entity. In some instances, the user input data 227 may include a top scoring ASR hypothesis of the ASR data. As an even further example, in some embodiments, the user input may correspond to an actuation of a physical button, data representing selection of a button displayed on a graphical user interface (GUI), image data of a gesture user input, combination of different types of user inputs (e.g., gesture and button actuation), etc. In such embodiments, the system 200 may include one or more components configured to process such user inputs to generate the text or tokenized representation of the user input (e.g., the user input data 227)…” Col. 5 Ln. 59-67, Col. 6 Ln. 1-5, Col. 18 Ln. 65-67, Col. 19 Ln. 1-67);
generating a first prompt (prompt) that includes a description of the query (LLM Orchestrator Component 130) (“…In some embodiments, the LLM orchestrator component 130 may generate prompt data representing a prompt for input to the language models. As shown in FIG. 2, the system component(s) 220 receive user input data 227, which may be provided to the LLM orchestrator component 130. In some instances, the user input data 227 may correspond to various data types, such as text (e.g., a text or tokenized representation of a user input), audio, image, video etc. For example, the user input data may include input text (or tokenized) data when the user input is a typed natural language user input. For further example, prior to the LLM orchestrator component 130 receiving the user input data 227, another component (e.g., an automatic speech recognition (ASR) component 650) of the system 200 may receive audio data representing the user input. The ASR component 650 may perform ASR processing on the audio data to determine ASR data corresponding to the user input, which may correspond to a transcript of the user input. As described below, with respect to FIG. 6, the ASR component 650 may determine ASR data that includes an ASR N-best list including multiple ASR hypotheses and corresponding confidence scores representing what the user may have said. The ASR hypotheses may include text data, token data, ASR confidence score, etc. as representing the input utterance. The confidence score of each ASR hypothesis may indicate a level of confidence of the ASR component 650 that the corresponding hypothesis represents what the user said. The ASR component 650 may also determine token scores corresponding to each token/word of the ASR hypothesis, where the token score indicates the level of confidence of the ASR component 650 that the respective token/word was spoken by the user. The token scores may be identified as an entity score when the corresponding token relates to an entity. In some instances, the user input data 227 may include a top scoring ASR hypothesis of the ASR data. As an even further example, in some embodiments, the user input may correspond to an actuation of a physical button, data representing selection of a button displayed on a graphical user interface (GUI), image data of a gesture user input, combination of different types of user inputs (e.g., gesture and button actuation), etc. In such embodiments, the system 200 may include one or more components configured to process such user inputs to generate the text or tokenized representation of the user input (e.g., the user input data 227)…” Col. 18 Ln. 65-67, Col. 19 Ln. 1-67) and selector information, the selector information including an instruction to select one or more functions from a group of functions, and a summary of the functions in the group of functions (“…The component shortlister 102 may process as described herein above to determine one or more components 112 (e.g., API(s), skill component(s) 254, LLM agent component(s) 252, TTS component 256, etc.) configured to perform an action related to the user input or the current task…” Col. 2 Ln. 28-37, Col. 20 Ln. 7-11, Ln. 32-47);
sending the first prompt to the machine-trained language model (Plan Generation Language Model 320) (“…As further shown in FIG. 3, the user input data 227 is received at the plan prompt generation component 310. The plan prompt generation component 310 processes the user input data 227 to generate prompt data 315 representing a prompt for input to the plan generation language model 320…In some embodiments, the plan prompt generation component 310 may also include in the prompt data 315 a sample processing format to be used by the plan generation language model 320 when processing the prompt. In some embodiments, the plan prompt generation component 310 may generate the prompt data 315 according to a template format. For example, the prompt data 315 may adhere to a template format of:…” Col. 22 Ln. 17-21, Col. 23 Ln. 46-53) and
receiving a first language-model response from the machine-trained language model that the machine-trained language model generates in response to the first prompt, the first language-model response including identification information that identifies a particular function specified in the group of functions (output/response) (“…The input to the LLM may be in the form of a prompt. A prompt may be a natural language input, for example, an instruction, for the LLM to generate an output according to the prompt. The output generated by the LLM may be a natural language output responsive to the prompt. In some embodiments, the output may be another type of data, such as audio, image, video, etc. The prompt, in some cases, can also include in-context learning information that may be used by the LLM to generate a response to the prompt…The action plan execution component 245 may identify the request(s) in the action plan data 242, generate executable API calls corresponding to the request(s), and cause the corresponding components (e.g., the API provider component 250, the LLM agent component 252, the skill component 254, and/or the TTS component 256) to generate action response data 258a-n representing the requested potential response(s), where individual action response data 258a may be provided by/correspond to a particular responding component-one of the API provider component 250, the LLM agent component 252, the skill component 254, and/or the TTS component 256. The action response data 258a-n may include various data types including audio, text, image, video, etc. In some embodiments, the action response data 258a-n may include an identifier (e.g., a component name, an alphanumerical value associated with the component, etc.) for the component providing the data. The component shortlister 102 receives and processes the action response data 258a-n and generates potential response data 243a-n representing the potential response(s) (e.g., relevant potential responses, selected potential responses, ranked potential responses, etc.) for further processing (e.g., as described in detail herein below with respect to FIG. 4). If the component shortlister 102 determines that there are no remaining tasks to generate potential responses for, the component shortlister 102 may send the potential response data 243a-n to the response arbitration component 260…” Col. 2 Ln. 28-37, Col. 20 Ln. 62-67, Col. 21 Ln. 1-21).
Kachuee is silent with reference to generating a second prompt that provides a particular instance of function definition information that describes the particular function in more detail than the selector information in the first prompt by specifying at least input information to be provided to the particular function, the second prompt having fewer tokens than an amount of tokens that would be needed to describe all of the functions in the group of functions;
sending the second prompt to the machine-trained language model;
receiving a second language-model response that the machine-trained language model generates in response to the second prompt, the second language-model response providing invocation information for invoking the particular function with input information that is formatted in a manner specified by the particular instance of function definition information; and
invoking the particular function specified by the invocation information.
Chakhvadze teaches generating a second prompt that provides a particular instance of function definition information that describes the particular function in more detail than the selector information in the first prompt by specifying at least input information to be provided to the particular function (the data management system generates a further prompt (e.g., the second prompt)) (“…In various embodiments, the data management system automatically handles error detection and correction based on model responses. Specifically, upon receiving a model response, the data management system determines if an error occurred during at least one of the operations, including the operation of parsing the response; the operation of validating the parsed response, and the operation of generating the one or more programming data objects in the requested machine-readable format. Once an error is detected, the data management system generates a further prompt (e.g., the second prompt) based on a text description of the error and the model response that includes the error. The data management system uses the machine learning model to generate a further model response (e.g., second response) in the output format (e.g., requested machine-readable format) based on the further prompt. Once the further model response is generated, the data management system parses the response, validates the response against the schema, and converts the response into one or more into one or more programming data objects in the requested machine-readable format. Upon determining the further model response is free from error, the data management system passes the one or more programming data objects as function outputs to the requesting user for downstream processing…” paragraph 0020), the second prompt having fewer tokens than an amount of tokens that would be needed to describe all of the functions in the group of functions (the token budget of each data chunk is dynamically calculated based on the current size of the internal state parameter, so that the number of tokens in the resulting prompt is not larger than the maximum number of tokens supported by the large language model) (“…At operation 608, the processor dynamically calculates a token budget based on an internal state parameter. The internal state parameter is updated before the processor identifies and process a next data chunk. As more data chunks are identified and processed, the size of the internal state parameter continues to grow. Given that the total length of model input and output is limited, the token budget of each data chunk is dynamically calculated based on the current size of the internal state parameter, so that the number of tokens in the resulting prompt is not larger than the maximum number of tokens supported by the large language model…” paragraph 0082),
sending the second prompt to the machine-trained language model/
receiving a second language-model response that the machine-trained language model generates in response to the second prompt, the second language-model response providing invocation information for invoking the particular function with input information that is formatted in a manner specified by the particular instance of function definition information (The data management system uses the machine learning model to generate a further model response (e.g., second response) in the output format (e.g., requested machine-readable format) based on the further prompt) (“…In various embodiments, calling a function can include specifying the function name, function definitions, function call operator, and data values (also referred to as arguments) the function expects to receive. Arguments are values for the parameters defined for the function. Arguments can be passed to the function provided by the data management system…In various embodiments, the data management system automatically handles error detection and correction based on model responses. Specifically, upon receiving a model response, the data management system determines if an error occurred during at least one of the operations, including the operation of parsing the response; the operation of validating the parsed response, and the operation of generating the one or more programming data objects in the requested machine-readable format. Once an error is detected, the data management system generates a further prompt (e.g., the second prompt) based on a text description of the error and the model response that includes the error. The data management system uses the machine learning model to generate a further model response (e.g., second response) in the output format (e.g., requested machine-readable format) based on the further prompt. Once the further model response is generated, the data management system parses the response, validates the response against the schema, and converts the response into one or more into one or more programming data objects in the requested machine-readable format. Upon determining the further model response is free from error, the data management system passes the one or more programming data objects as function outputs to the requesting user for downstream processing…At operation 606, the processor processes the collection of data units to generate a plurality of outputs. The processing of the collection can include a number of operations, such as operations 608 through 614. In various embodiments, data management system can provide one or more functions that can be called to handles the processing of the collection of data units. For example, inputs to a function that is provided to processing of the collection of data units can include instruction prompt template, zero or more arguments (also referred to as function parameters, or parameters) passed as symbolic chunk iterators, and zero or more arguments representing internal state parameter. Example outputs of such a function can include a final results that includes aggregated (or merged) outputs resulting from the processing of the collection…” paragraphs 0018/0020/0081), and
invoking the particular function specified by the invocation information (“…In various embodiments, calling a function can include specifying the function name, function definitions, function call operator, and data values (also referred to as arguments) the function expects to receive. Arguments are values for the parameters defined for the function. Arguments can be passed to the function provided by the data management system…The API server 110 receives and transmits data (e.g., API calls, commands, requests, responses, and authentication data) between the client device 102 and the application server 116. Specifically, the API server 110 provides a set of interfaces (e.g., routines and protocols) that can be called or queried by the client software application 104 in order to invoke the functionality of the application server 116. The API server 110 exposes various functions supported by the application server 116 including, without limitation: user registration; login functionality; data object operations (e.g., generating, storing, retrieving, encrypting, decrypting, transferring, access rights, licensing, etc.); and user communications…” paragraph 0046).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Kachuee with the teaching of Chakhvadze because the teaching of Chakhvadze would improve the system of Kachuee by providing a token budget determining component for dynamically calculating token budget based on an internal state (also referred to as an internal state parameter) and corresponding to a number of tokens that exceeds an upper limit of tokens (e.g., the token budget) that a large language model can process (Chakhvadze paragraph 0056).
As to claim 2, Kachuee teaches the method of claim 1, further comprising:
receiving reference information that describes functions from at least one reference source (“…The component shortlister 102 may process as described herein above to determine one or more components 112 (e.g., API(s), skill component(s) 254, LLM agent component(s) 252, TTS component 256, etc.) configured to perform an action related to the user input or the current task…” Col. 2 Ln. 28-37, Col. 20 Ln. 7-11, Ln. 32-47); and
using the machine-trained language model to transform the reference information into the selector information and instances of function definition information that describe the functions in the group of functions (“…The component shortlister 102 may process as described herein above to determine one or more components 112 (e.g., API(s), skill component(s) 254, LLM agent component(s) 252, TTS component 256, etc.) configured to perform an action related to the user input or the current task…” Col. 2 Ln. 28-37, Col. 20 Ln. 7-11, Ln. 32-47).
As to claim 3, Kachuee teaches the method of claim 1, further comprising:
receiving the selector information from a repository that includes different pre-generated instances of selector information (Component Shortlister 102); and
receiving pre-generated instances of function description information from the repository that describe respective functions in the group of functions (“…The component shortlister 102 may process as described herein above to determine one or more components 112 (e.g., API(s), skill component(s) 254, LLM agent component(s) 252, TTS component 256, etc.) configured to perform an action related to the user input or the current task…” Col. 2 Ln. 28-37, Col. 20 Ln. 7-11, Ln. 32-47).
As to claim 4, Chakhvadze teaches the method of claim 1, wherein the invocation information in the second language-model response is application programming interface information (“…In various embodiments, calling a function can include specifying the function name, function definitions, function call operator, and data values (also referred to as arguments) the function expects to receive. Arguments are values for the parameters defined for the function. Arguments can be passed to the function provided by the data management system…The API server 110 receives and transmits data (e.g., API calls, commands, requests, responses, and authentication data) between the client device 102 and the application server 116. Specifically, the API server 110 provides a set of interfaces (e.g., routines and protocols) that can be called or queried by the client software application 104 in order to invoke the functionality of the application server 116. The API server 110 exposes various functions supported by the application server 116 including, without limitation: user registration; login functionality; data object operations (e.g., generating, storing, retrieving, encrypting, decrypting, transferring, access rights, licensing, etc.); and user communications…” paragraph 0046).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Kachuee with the teaching of Chakhvadze because the teaching of Chakhvadze would improve the system of Kachuee by providing a token budget determining component for dynamically calculating token budget based on an internal state (also referred to as an internal state parameter) and corresponding to a number of tokens that exceeds an upper limit of tokens (e.g., the token budget) that a large language model can process (Chakhvadze paragraph 0056).
As to claim 6, Chakhvadze teaches the method of claim 1, further comprising generating successive prompts (the data management system generates a further prompt (e.g., the second prompt) and receiving successive language-model responses until a particular language-model response indicates that the particular language-model response is a final response (generate a further model response (e.g., second response)) (“…In various embodiments, the data management system automatically handles error detection and correction based on model responses. Specifically, upon receiving a model response, the data management system determines if an error occurred during at least one of the operations, including the operation of parsing the response; the operation of validating the parsed response, and the operation of generating the one or more programming data objects in the requested machine-readable format. Once an error is detected, the data management system generates a further prompt (e.g., the second prompt) based on a text description of the error and the model response that includes the error. The data management system uses the machine learning model to generate a further model response (e.g., second response) in the output format (e.g., requested machine-readable format) based on the further prompt. Once the further model response is generated, the data management system parses the response, validates the response against the schema, and converts the response into one or more into one or more programming data objects in the requested machine-readable format. Upon determining the further model response is free from error, the data management system passes the one or more programming data objects as function outputs to the requesting user for downstream processing…At operation 606, the processor processes the collection of data units to generate a plurality of outputs. The processing of the collection can include a number of operations, such as operations 608 through 614. In various embodiments, data management system can provide one or more functions that can be called to handles the processing of the collection of data units. For example, inputs to a function that is provided to processing of the collection of data units can include instruction prompt template, zero or more arguments (also referred to as function parameters, or parameters) passed as symbolic chunk iterators, and zero or more arguments representing internal state parameter. Example outputs of such a function can include a final results that includes aggregated (or merged) outputs resulting from the processing of the collection…” paragraphs 0018/0020/0081).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Kachuee with the teaching of Chakhvadze because the teaching of Chakhvadze would improve the system of Kachuee by providing a token budget determining component for dynamically calculating token budget based on an internal state (also referred to as an internal state parameter) and corresponding to a number of tokens that exceeds an upper limit of tokens (e.g., the token budget) that a large language model can process (Chakhvadze paragraph 0056).
As to claim 14, Kachuee teaches the method of claim 1, wherein the particular function is a computer program and/or or machine-trained model that accepts a particular input, performs particular operations on the input, and delivers a particular output as an outcome of the operations (“…The component shortlister 102 may process as described herein above to determine one or more components 112 (e.g., API(s), skill component(s) 254, LLM agent component(s) 252, TTS component 256, etc.) configured to perform an action related to the user input or the current task…” Col. 2 Ln. 28-37, Col. 20 Ln. 7-11, Ln. 32-47).
As to claim 15, Kachuee teaches a computing system for processing a query using a machine-trained language model, comprising:
an instruction data store for storing computer-readable instructions (Storage 1008); and
a processing system for executing the computer-readable instructions in the data store (Controllers/Processors 1004), to perform operations including:
receiving the query (input/Request 104/User Input Data 227) (“…The input to the LLM may be in the form of a prompt. A prompt may be a natural language input, for example, an instruction, for the LLM to generate an output according to the prompt. The output generated by the LLM may be a natural language output responsive to the prompt. In some embodiments, the output may be another type of data, such as audio, image, video, etc. The prompt, in some cases, can also include in-context learning information that may be used by the LLM to generate a response to the prompt…FIG. 1A illustrates the component shortlister 102, according to various embodiments of the present disclosure. As shown in FIG. 1A, the component shortlister 102 takes as input a request 104 that may be a request to perform a task. In some cases, the request 104 may be a request that is to be provided to a LLM for processing. The component shortlister 102 may also optionally take as input a namespace 106, to focus shortlisting to components within the namespace, and/or max entries 108 to control the number of components 112 the component shortlister 102 outputs. As used herein, a “namespace” refers to a grouping of components based on topic/subject matter. Example namespaces includes, but are not limited to, music, smart home, weather, food ordering, ride sharing, travel, and video…In some embodiments, the LLM orchestrator component 130 may generate prompt data representing a prompt for input to the language models. As shown in FIG. 2, the system component(s) 220 receive user input data 227, which may be provided to the LLM orchestrator component 130. In some instances, the user input data 227 may correspond to various data types, such as text (e.g., a text or tokenized representation of a user input), audio, image, video etc. For example, the user input data may include input text (or tokenized) data when the user input is a typed natural language user input. For further example, prior to the LLM orchestrator component 130 receiving the user input data 227, another component (e.g., an automatic speech recognition (ASR) component 650) of the system 200 may receive audio data representing the user input. The ASR component 650 may perform ASR processing on the audio data to determine ASR data corresponding to the user input, which may correspond to a transcript of the user input. As described below, with respect to FIG. 6, the ASR component 650 may determine ASR data that includes an ASR N-best list including multiple ASR hypotheses and corresponding confidence scores representing what the user may have said. The ASR hypotheses may include text data, token data, ASR confidence score, etc. as representing the input utterance. The confidence score of each ASR hypothesis may indicate a level of confidence of the ASR component 650 that the corresponding hypothesis represents what the user said. The ASR component 650 may also determine token scores corresponding to each token/word of the ASR hypothesis, where the token score indicates the level of confidence of the ASR component 650 that the respective token/word was spoken by the user. The token scores may be identified as an entity score when the corresponding token relates to an entity. In some instances, the user input data 227 may include a top scoring ASR hypothesis of the ASR data. As an even further example, in some embodiments, the user input may correspond to an actuation of a physical button, data representing selection of a button displayed on a graphical user interface (GUI), image data of a gesture user input, combination of different types of user inputs (e.g., gesture and button actuation), etc. In such embodiments, the system 200 may include one or more components configured to process such user inputs to generate the text or tokenized representation of the user input (e.g., the user input data 227)…” Col. 5 Ln. 59-67, Col. 6 Ln. 1-5, Col. 18 Ln. 65-67, Col. 19 Ln. 1-67);
in a first prompting operation, asking the machine-trained model to select a particular application programming interface (API) to be called in responding to the query, from a group of APIs (“…The component shortlister 102 may process as described herein above to determine one or more components 112 (e.g., API(s), skill component(s) 254, LLM agent component(s) 252, TTS component 256, etc.) configured to perform an action related to the user input or the current task…” Col. 2 Ln. 28-37, Col. 20 Ln. 7-11, Ln. 32-47); and
receiving a first language-model response from the machine-trained language model that provides identification information that identifies the particular API in the group of APIs that is selected (output/response) (“…The input to the LLM may be in the form of a prompt. A prompt may be a natural language input, for example, an instruction, for the LLM to generate an output according to the prompt. The output generated by the LLM may be a natural language output responsive to the prompt. In some embodiments, the output may be another type of data, such as audio, image, video, etc. The prompt, in some cases, can also include in-context learning information that may be used by the LLM to generate a response to the prompt…The action plan execution component 245 may identify the request(s) in the action plan data 242, generate executable API calls corresponding to the request(s), and cause the corresponding components (e.g., the API provider component 250, the LLM agent component 252, the skill component 254, and/or the TTS component 256) to generate action response data 258a-n representing the requested potential response(s), where individual action response data 258a may be provided by/correspond to a particular responding component-one of the API provider component 250, the LLM agent component 252, the skill component 254, and/or the TTS component 256. The action response data 258a-n may include various data types including audio, text, image, video, etc. In some embodiments, the action response data 258a-n may include an identifier (e.g., a component name, an alphanumerical value associated with the component, etc.) for the component providing the data. The component shortlister 102 receives and processes the action response data 258a-n and generates potential response data 243a-n representing the potential response(s) (e.g., relevant potential responses, selected potential responses, ranked potential responses, etc.) for further processing (e.g., as described in detail herein below with respect to FIG. 4). If the component shortlister 102 determines that there are no remaining tasks to generate potential responses for, the component shortlister 102 may send the potential response data 243a-n to the response arbitration component 260…” Col. 2 Ln. 28-37, Col. 20 Ln. 62-67, Col. 21 Ln. 1-21).
Kachuee is silent with reference to in a second prompting operation, asking the machine-trained language model to generate an API message to be input to the particular API that conforms to a particular instance of function definition information that describes the particular API, the second prompting operation producing fewer tokens than an amount of tokens that would be needed to describe all of the APIs in the group of APIs,
receiving a second language-model response that includes the API message that is generated, to be input to the particular API, and
sending the API message to the particular API to invoke the particular API.
Chakhvadze teaches in a second prompting operation, asking the machine-trained language model to generate an API message to be input to the particular API that conforms to a particular instance of function definition information that describes the particular API (the data management system generates a further prompt (e.g., the second prompt)) (“…In various embodiments, the data management system automatically handles error detection and correction based on model responses. Specifically, upon receiving a model response, the data management system determines if an error occurred during at least one of the operations, including the operation of parsing the response; the operation of validating the parsed response, and the operation of generating the one or more programming data objects in the requested machine-readable format. Once an error is detected, the data management system generates a further prompt (e.g., the second prompt) based on a text description of the error and the model response that includes the error. The data management system uses the machine learning model to generate a further model response (e.g., second response) in the output format (e.g., requested machine-readable format) based on the further prompt. Once the further model response is generated, the data management system parses the response, validates the response against the schema, and converts the response into one or more into one or more programming data objects in the requested machine-readable format. Upon determining the further model response is free from error, the data management system passes the one or more programming data objects as function outputs to the requesting user for downstream processing…” paragraph 0020),
the second prompting operation producing fewer tokens than an amount of tokens that would be needed to describe all of the APIs in the group of APIs (the token budget of each data chunk is dynamically calculated based on the current size of the internal state parameter, so that the number of tokens in the resulting prompt is not larger than the maximum number of tokens supported by the large language model) (“…At operation 608, the processor dynamically calculates a token budget based on an internal state parameter. The internal state parameter is updated before the processor identifies and process a next data chunk. As more data chunks are identified and processed, the size of the internal state parameter continues to grow. Given that the total length of model input and output is limited, the token budget of each data chunk is dynamically calculated based on the current size of the internal state parameter, so that the number of tokens in the resulting prompt is not larger than the maximum number of tokens supported by the large language model…” paragraph 0082),
receiving a second language-model response that includes the API message that is generated, to be input to the particular API, and
sending the API message to the particular API to invoke the particular API (“…In various embodiments, calling a function can include specifying the function name, function definitions, function call operator, and data values (also referred to as arguments) the function expects to receive. Arguments are values for the parameters defined for the function. Arguments can be passed to the function provided by the data management system…The API server 110 receives and transmits data (e.g., API calls, commands, requests, responses, and authentication data) between the client device 102 and the application server 116. Specifically, the API server 110 provides a set of interfaces (e.g., routines and protocols) that can be called or queried by the client software application 104 in order to invoke the functionality of the application server 116. The API server 110 exposes various functions supported by the application server 116 including, without limitation: user registration; login functionality; data object operations (e.g., generating, storing, retrieving, encrypting, decrypting, transferring, access rights, licensing, etc.); and user communications…” paragraph 0046).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Kachuee with the teaching of Chakhvadze because the teaching of Chakhvadze would improve the system of Kachuee by providing a token budget determining component for dynamically calculating token budget based on an internal state (also referred to as an internal state parameter) and corresponding to a number of tokens that exceeds an upper limit of tokens (e.g., the token budget) that a large language model can process (Chakhvadze paragraph 0056).
As to claim 20, see the rejection of claim 1, expect for a computer-readable storage medium.
Kachuee teaches a computer-readable storage medium (Storage 1008).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 12,626,698 A1 issued to Kachuee et al. in view of U.S. Pub. No. 2025/0045025 A1 to Chakhvadze et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 20140089911 A1 to Allan et al.
As to claim 10, Kachuee as modified Chakhvadze teaches the method of claim 1, however it is silent with reference to automatically removing the particular instance of function definition information from a context data store upon a determination that a triggering event has occurred that indicates that the particular instance of function definition information is no longer needed.
Allan teaches automatically removing the particular instance of function definition information from a context data store upon a determination that a triggering event (Steps 109/Step 115) has occurred that indicates that the particular instance of function definition information is no longer needed (“…The unified functions resultant from analysis are stored in a repository (step 101). The repository may be repository 53 shown in FIG. 1. Unified functions are functions that have been rationalized and combined based on their description, which indicates that the functions perform similar capabilities with only slight variations. The similar functionality analysis removes duplications and ensures function or candidate service connections by: identifying functions with similar names and identical functionality; identifying functions with similar names but different functionality to eliminate all duplication functions using function description as a basis; identifying functions with different names, but identical functionality to group functions with some variations in functionality, but with overlapping commonality under a course grained facade function; ensure function name and description for correctness by accepting, deleting, or fixing; and related functions to facades. Once the similar functionality analysis is complete, the analysis may include: the function/candidate name, function description; action resulting from analysis of accepted, added, deleted, or unified; the unified function name, and the facade for a course grained function that can be supported by finer grained functions, for example as shown in FIGS. 10-13. Step 101 is further described in FIGS. 3-5…The functions resultant from the similar functionality analysis are retrieved from the repository and a pivot table is created with the unified functions (step 102), for example by the pivot table creator program 67. The functions within the pivot table are categorized (step 103). The categorization includes categorizing based on operation the function or candidate service performs through create, read, update, delete, technical functions, and wrongly placed (CRUDTW) operations, the functional area the candidate service or function should belong to and the business activity type. The categorization is preferably based on the function or candidate service description…” paragraphs 0038/0039).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Kachuee and Chakhvadze with the teaching of Alan because the teaching of Alan would improve the system of Kachuee and Chakhvadze by providing a similar functionality analysis applied to functions to remove duplications, unify functions, and ensure function or candidate service connections and for optimal function invocation (Allan paragraph 0037).
Claims 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 12,626,698 A1 issued to Kachuee et al. in view of U.S. Pub. No. 2025/0045025 A1 to Chakhvadze et al. as applied to claim 10 above, and further in view of U.S. Pub. No. 20140089911 A1 to Allan et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 2025/0103401 A1 to Singh.
As to claim 11, Kachuee as modified Chakhvadze and Alan teaches the method of claim 10, however it is silent with reference to wherein one triggering event is an indication that the particular function associated with the particular instance of function information has been invoked.
Singh teaches wherein one triggering event is an indication that the particular function associated with the particular instance of function information has been invoked (initiating, based on receipt by a prompt module, one of a user-request requirement and a repository-optimization trigger/to remove obsolete APIs from the distributed API repository based on the mergeable APIs that were merged) (“…In some arrangements, an artificial-intelligence merger, construction, and optimization method for application program interfaces can comprise one or more steps such as, for example: initiating, based on receipt by a prompt module, one of a user-request requirement and a repository-optimization trigger, an application program interface (API) merge and create process to merge mergeable APIs stored in a distributed API repository into a constructed API that is newly created and to remove obsolete APIs from the distributed API repository based on the mergeable APIs that were merged; extracting, by a metadata extraction module, API metadata for the mergeable APIs from the distributed API repository; generating, by an analyzer module based on a generative artificial intelligence (AI) process executing deep-learning abstract syntax tree (AST) and generative pre-trained transformer (GPT) algorithms, API clusters containing combinable APIs from the mergeable APIs based on the API metadata that was extracted; generating, by the API analyzer using the generative AI process, telemetry for the API clusters to identify an API solution cluster for the combinable APIs based on which of the API clusters had a highest performance ranking in view of execution speed, predicted reliability, security, and scalability; combining, by a generation module consistent with API security-rule requirements, the combinable APIs identified by the API solution cluster into the constructed API; creating, by the generation module, constructed metadata for the constructed API; testing, by a smart contract module, the constructed API as a smart contract to obtain operability test results on the constructed API, said smart contract being a self-executing contract with agreement terms for software API testing written into code for the smart contract, said smart contract stored on a distributed ledger blockchain; transmitting, by the smart contract module to the generative AI process, the operability test results based on execution of the smart contract with respect to the constructed API; storing, in the distributed API repository, the constructed API with the constructed metadata; removing, from the distributed API repository, any of said combinable APIs and any of said API metadata that is obsolete in view of the constructed API; deploying, by an orchestration module, the constructed API to the distributed ledger blockchain; monitoring, continuously by an API monitoring module, the distributed ledger blockchain to observe performance metrics for the constructed API; transmitting, by the API monitoring module to the generative AI process, the performance metrics; ingesting, into the generative AI process, the operability test results and the performance metrics; mapping, to the constructed API in the distributed API repository, future process calls to any of said combinable APIs that were rendered obsolete; and/or providing, by the API merge and create process, developer notifications for any of said combinable APIs that were rendered obsolete…” paragraphs 0011/0051).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Kachuee and Chakhvadze with the teaching of Singh because the teaching of Singh would improve the system of Kachuee and Chakhvadze by providing a technique for removing or deleting obsolete functions/API to allow for optimal function invocation.
As to claim 12, Kachuee as modified Chakhvadze and Alan teaches the method of claim 10, however it is silent with reference to wherein one triggering event is an indication that another query has been received for which the particular function associated with the particular instance of function definition information is unusable.
Singh teaches wherein one triggering event is an indication that another query has been received for which the particular function associated with the particular instance of function definition information is unusable (to remove obsolete APIs from the distributed API repository based on the mergeable APIs that were merged) (“…In some arrangements, an artificial-intelligence merger, construction, and optimization method for application program interfaces can comprise one or more steps such as, for example: initiating, based on receipt by a prompt module, one of a user-request requirement and a repository-optimization trigger, an application program interface (API) merge and create process to merge mergeable APIs stored in a distributed API repository into a constructed API that is newly created and to remove obsolete APIs from the distributed API repository based on the mergeable APIs that were merged; extracting, by a metadata extraction module, API metadata for the mergeable APIs from the distributed API repository; generating, by an analyzer module based on a generative artificial intelligence (AI) process executing deep-learning abstract syntax tree (AST) and generative pre-trained transformer (GPT) algorithms, API clusters containing combinable APIs from the mergeable APIs based on the API metadata that was extracted; generating, by the API analyzer using the generative AI process, telemetry for the API clusters to identify an API solution cluster for the combinable APIs based on which of the API clusters had a highest performance ranking in view of execution speed, predicted reliability, security, and scalability; combining, by a generation module consistent with API security-rule requirements, the combinable APIs identified by the API solution cluster into the constructed API; creating, by the generation module, constructed metadata for the constructed API; testing, by a smart contract module, the constructed API as a smart contract to obtain operability test results on the constructed API, said smart contract being a self-executing contract with agreement terms for software API testing written into code for the smart contract, said smart contract stored on a distributed ledger blockchain; transmitting, by the smart contract module to the generative AI process, the operability test results based on execution of the smart contract with respect to the constructed API; storing, in the distributed API repository, the constructed API with the constructed metadata; removing, from the distributed API repository, any of said combinable APIs and any of said API metadata that is obsolete in view of the constructed API; deploying, by an orchestration module, the constructed API to the distributed ledger blockchain; monitoring, continuously by an API monitoring module, the distributed ledger blockchain to observe performance metrics for the constructed API; transmitting, by the API monitoring module to the generative AI process, the performance metrics; ingesting, into the generative AI process, the operability test results and the performance metrics; mapping, to the constructed API in the distributed API repository, future process calls to any of said combinable APIs that were rendered obsolete; and/or providing, by the API merge and create process, developer notifications for any of said combinable APIs that were rendered obsolete…” paragraphs 0011/0051).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Kachuee and Chakhvadze with the teaching of Singh because the teaching of Singh would improve the system of Kachuee and Chakhvadze by providing a technique for removing or deleting obsolete functions/API to allow for optimal function invocation.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 12,626,698 A1 issued to Kachuee et al. in view of U.S. Pub. No. 2025/0045025 A1 to Chakhvadze et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 2025/0103367 A1 to Shipkovenski et al.
As to claim 13, Kachuee as modified Chakhvadze teaches the method of claim 1, however it is silent with reference to wherein a first function in the group of functions receives input information generated by a second function in the group of functions, and wherein two or more functions in the group of functions perform, at least in part, the same operations.
Shipkovenski teaches wherein a first function (API Call 150) in the group of functions receives input information generated by a second function in the group of functions (Second API Call 155), and wherein two or more functions in the group of functions perform, at least in part, the same operations (performs the same operation) (“…At a FaaS framework executing in a first cloud, the method receives a first API (Application Programming Interface) call invoking a first function that is defined by the framework. At the FaaS framework, the method generates, from the first API call, a second API call that directs a set of machines in a second cloud to invoke a second function that performs a desired operation of the first function in the second cloud. The method forwards, at the FaaS framework, the second API call to the second cloud for the set of machines to instantiate the second function after receiving the second API call, to use the second function to perform the desired operation, and to discard the second function after performing the desired operation…Based on the API call 150 received from the program 110, the SDK 120 of some embodiments selects a cloud provider from the available cloud providers 130-134, and generates a second API call 155 to invoke the function named in the first API call 150. In some embodiments, the second API call 155 is in a second format that is compatible with the selected cloud provider. In some embodiments, the function named in the API call 150 is a first function, and the function retrieved by the SDK 120 is a second function that when executed, performs the same operation, and produces the same results, as the named first function…” paragraphs 0004/0035).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Kachuee and Chakhvadze with the teaching of Shipkovenski because the teaching of Shipkovenski would improve the system of Kachuee and Chakhvadze by providing a FaaS framework that allows for plural cloud providers for services function calls or invocation.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 12,626,698 A1 issued to Kachuee et al. in view of U.S. Pub. No. 2025/0045025 A1 to Chakhvadze et al. as applied to claim 15 above, and further in view of U.S. Pub. No. 2018/0260374 A1 to Sobby et al.
As to claim 17, Kachuee as modified Chakhvadze teaches the computing system of claim 15, however it is silent with reference to wherein the operations are repeated one or more times to invoke plural function calls in series.
Sobby teaches wherein the operations are repeated one or more times to invoke plural function calls in series (recursive functions/ further function calls) (“…In some examples, the functions comprise multi-step functions, recursive functions, or nested functions, among others. These functions might require more than one execution step or function call to complete and determine a result. In these cases, asynchronous function handler 123 can handle evaluation of the functions by issuing a series of function calls out to the appropriate function platform. Each intermediate result received from the function platform can be cached or otherwise stored by asynchronous function handler. These intermediate results can be employed in further function calls to produce a final evaluated result based on the intermediate results and one or more repeated function calls. A further discussion on these multi-step function calls is discussed below in FIGS. 3 and 4…” paragraph 0025).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Kachuee and Chakhvadze with the teaching of Sobby because the teaching of Sobby would improve the system of Kachuee and Chakhvadze by providing a recursive learning process where a function, algorithm, or model learns or operates by repeatedly by applying itself to smaller instances of the same problem until a preferred or optimal condition is met
Allowable Subject Matter
Claims 5, 7-9, 16, 18 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Reasons for allowance
The following is an examiner’s statement of reasons for allowance:
The closest prior art of records, (U.S. Pub. No. 12,626,698 A1 issued to Kachuee et al. and U.S. Pub. No. 2025/0045025 A1 to Chakhvadze et al.), taken alone or in combination do not specifically disclose or suggest the claimed recitations (claims 5, 7-9, 16, 18 and 19), when taken in the context of claims as a whole.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Response to Arguments
Applicant’s arguments with respect to claims 1-4, 6, 10-15, 17 and 20 have been considered but are moot because the new ground of rejection relied on additional references not applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
