DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
All objections/rejections not mentioned in this Office Action have been withdrawn by the Examiner.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 06 November 2025 and 01 February 2026 is/are being considered by the examiner.
Status of the Claims
Prior to entry of the amendment(s) and/or consideration of the argument(s), the status of the claims is as follows.
Claim(s) 1-20 is/are pending.
Claim(s) 1, 8, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige (U.S. Pat. App. Pub. No. 2025/0094821, hereinafter Hettige) in view of Kotikalapudi (U.S. Pat. App. Pub. No. 2024/0394471, hereinafter Kotikalapudi).
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige and Kotikalapudi as applied to claim(s) 1 above, and further in view of deLevie (U.S. Pat. App. Pub. No. 2025/0061279, hereinafter deLevie).
Claims 3-6 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige and Kotikalapudi as applied to claim(s) 2 and 19 above, and further in view of deLevie and Watson (U.S. Pat. App. Pub. No. 2024/0319970, hereinafter Watson).
Claims 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige, Kotikalapudi, deLevie, and Watson as applied to claim 6 above, and further in view of Cohen (U.S. Pat. App. Pub. No. 2018/0308481, hereinafter Cohen).
Claims 9-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige and Kotikalapudi as applied to claim 8 above, and further in view of Cohen.
Claim(s) 14-15 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige in view of deLevie and Watson.
Claims 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige, deLevie and Watson as applied to claim 15 above, and further in view of Lightbody (U.S. Pat. App. Pub. No. 2024/0095682, hereinafter Lightbody).
Response to Amendments
Applicant’s amendment filed on 10 December 2025 has been entered.
In view of the amendment to the claim(s), the amendment of claim(s) 1, 3-7, 14, and 19-20 have been acknowledged and entered.
In view of the amendment to claim(s) 1, 3-7, 14, and 19-20, the rejection of claims 1-20 under 35 U.S.C. §103 is withdrawn.
In light of the amended claims, new grounds for rejection under 35 U.S.C. §103 are provided in the action below.
Response to Arguments
Applicant’s arguments regarding the specification objections, see page 9 of the Response to Non-Final Office Action dated 22 September 2025, which was received on 10 December 2025 (hereinafter Response and Office Action, respectively), have been fully considered. However, the arguments are not persuasive.
Respectfully, the question at issue regarding new matter is not one of intent when amending, but one of timing of the incorporation. The contents of the specification, including any matter incorporated by reference, is established at filing. (See 35 U.S.C. 111 and 112). Applicant's assertions regarding 37 C.F.R. 1.57(c)(1) are duly noted. However, 37 C.F.R. 1.57(c)(1) is an exclusive provision of a curative rule, not a permissive provision of a creation rule. To state this another way, 37 C.F.R. 1.57(c)(1) provides a means to cure a defective incorporation by reference, but it is exclusive because you must have used the root words “incorporate by reference” to rely on the recited provision. 37 C.F.R. 1.57(c)(1) does not define what an incorporation by reference is, nor does it otherwise allow the inclusion of new matter, even if the words “incorporation” and “reference” are avoided.
Prior to consideration of whether a preliminary amendment is a proper incorporation by reference under 37 CFR 1.57(c)(1), said preliminary amendment must first be analyzed under 37 CFR 1.115, which defines preliminary amendments, and 37 CFR 1.121, regarding the manner of making amendments. 37 CFR 1.115 states that “A preliminary amendment is an amendment that is received in the Office (§ 1.6) on or before the mail date of the first Office action” (37 CFR 1.115(a)) and “A preliminary amendment filed after the filing date of the application is not part of the original disclosure of the application.” (37 CFR 1.115(a)(2)).
As explained in 37 C.F.R. 1.121(f), regarding the manner of making amendments, “No amendment may introduce new matter into the disclosure of an application,” and proper objection such amendments within the specification is provided for at 35 USC 132. New matter is defined as “subject matter not present in the specification, claims, or drawings on the application filing date.” (MPEP 608.04). Further, though “new matter” is “ordinarily entered” upon submission, the new matter should be objected to under 35 USC 132 and upon said objection, the new matter “is required to be canceled from the descriptive portion of the specification.” (See MPEP 608.04).
As applied to the facts of the present application, the amendment to incorporate Radford is a preliminary amendment directed to new matter, as well as an impermissible incorporation by reference. The application was filed on 07 December 2023. The Radford reference was first disclosed to the Office in an Information Disclosure Statement (IDS) on 25 October 2024. The amendment to incorporate the Radford reference into paragraph [0032] was received by the Office on 11 March 2025, which is 15 months after the date of filing (considerably beyond the filing date). The Radford reference was not expressly disclosed in any way until 10 months after the filing date, as part of a supplemental IDS. Further, other than the general connection of discussing generative language models, there is no known connection between the Radford reference and the instant application which could be viewed as an implied or inherent disclosure. As such, this preliminary amendment is not part of the original disclosure, because the reference to Radford is not, in fact, “present in the specification, claims, or drawings on the application filing date.”
The response describing Radford as an “external resource where additional material can be found” is appreciated. However, the Office maintains that the contents of the specification are established when the application is filed and amendments must be directed to those established contents without including new matter. (See MPEP 608.04 citing 35 USC 132). Respectfully, a new matter rejection does not turn on the indicated intended use of the new matter, but whether the matter is present in the disclosure as filed. Therefore, the objection is maintained.
Applicant’s arguments regarding the prior art rejections under 35 U.S.C. §103, see pages 9-13 of the Response, have been fully considered.
With respect to the rejection(s) of claim(s) 1, 14, and 19 under 35 U.S.C. §103 in light of Hettige in view of Kotikalapudi, applicant asserts that the references fail to teach or suggest all limitations of the independent claims as amended. Applicant’s arguments in light of the amended claims are persuasive. Therefore, the rejections are withdrawn.
Applicant further argues that the rejection(s) of dependent claims 2-13, 15-18, and 20 should be withdrawn for at least the same reasons as independent claims 1, 14, and 19. Applicant’s arguments in light of the amended claims are persuasive. As such, the rejections of claims 2-13, 15-18, and 20 under 35 U.S.C. §103 are withdrawn.
However, upon further consideration, new ground(s) of rejection under 35 U.S.C. §103 are made in light of combinations of Hettige, Watson, and Cohen, and newly cited references Non-Patent Literature to Ramamonjison (Ramamonjison, R., Yu, T.T., Li, R., Li, H., Carenini, G., Ghaddar, B., He, S., Mostajabdaveh, M., Banitalebi-Dehkordi, A., Zhou, Z. and Zhang, Y., 2023. NL4Opt Competition: Formulating Optimization Problems Based on Their Natural Language Descriptions. arXiv preprint arXiv:2303.08233, hereinafter Ramamonjison), Non-Patent Literature to Mitchell (Mitchell, Eric, et al. “Enhancing self-consistency and performance of pre-trained language models through natural language inference.” Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing. 2022, hereinafter Mitchell), and Non-Patent Literature to Patil (Patil, S.G., Zhang, T., Wang, X. and Gonzalez, J.E., 2023. Gorilla: Large Language Model Connected with Massive APIs. arXiv preprint arXiv:2305.15334, hereinafter Patil).
The Applicant has not provided any further statement and therefore, the Examiner directs the Applicant to the below rationale.
Specification
The amendment filed 11 March 2025 is objected to under 35 U.S.C. 132(a) because it introduces new matter into the disclosure. 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. The added material which is not supported by the original disclosure is as follows:
In the preliminary amendment filed on 11 March 2025, applicant amended paragraph [0032] to incorporate the recitation “(Radford, et al., ‘Improving language understanding by generative pre-training,’ 2018)”. However, the reference was not part of the original disclosure, as it was first disclosed in the IDS filed on 25 October 2025, and incorporates new information which was not part of the application as filed. Though the application as filed does disclose and rely on a generative language model, it is not clear from the application as filed that the details of the Radford reference in particular were considered part of the original disclosure at the time of filing. Further, the breadth of the disclosure in the Radford reference and the specific components described therein go far beyond any equivalent structures described in the specification of the application as filed, such that the incorporation of the Radford reference cannot be fairly described as rephrasing or correction of obvious errors. Therefore, the preliminary amendment incorporating the Radford reference is not supported by the specification as filed and constitutes new matter.
Applicant is required to cancel the new matter in the reply to this Office Action.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1, 8, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige in view of Ramamonjison and Mitchell.
Regarding claim 1, Hettige discloses A computer-implemented method comprising (Systems and methods described with reference to a digital assistant, as implemented in a computing environment 200; Hettige, ¶ [0055]): receiving natural language inputs from a user, the natural language inputs specifying preferences of the user in natural language (As described with reference to an example, “it is assumed that a user ‘David’ is interested in making a change to his 401k contribution, and in an utterance 202, David provides the following input: Hi, how are you, I want to make a change to my 401k contribution. The utterance 202 can be communicated to the digital assistant (e.g., via a digital assistant user interface such as a text dialogue box or microphone).”; Hettige, ¶ [0056]); generating constraint management prompts for a generative language model (“The list of candidate agents and/or actions with associated metadata is appended to the utterance 202 and/or action performed by the user to construct an input prompt 227 {constraint management prompts} for the LLM 216. {generative language model}”; Hettige, ¶ [0063]), the constraint management prompts being based on the natural language inputs (The input prompt 227 generated from the utterance 202, and thus is based on the utterance 202; Hettige, ¶ [0063]); inputting the constraint management prompts to the generative language model (The input prompt 227 is sent to the LLM 216 to be processed.; Hettige, ¶ [0063]); outputting the candidate solutions to the user (“the output pipeline 270 transmits the responses 272 to the end user such as via a user device or interface” which can include requesting information regarding alternative execution plans where “the LLM 236 generates another response 272 prompting the user for the missing information (Would you like to change your contribution by percentage or amount?[Percentage][Amount]).” Though referred to as “missing information”, it would be understood to one having ordinary skill in the art that, as this appears to occur after the generation of the execution plan 210, said missing information clearly does not result in failure to generate the “execution plan 210” in the described embodiment of para [0080]. As such, the missing information is understood as a selection between separate implementations resulting in separate execution plans 210, each of which is presented to the user “via the user device or interface” for selection and subsequent implementation based on said selection.; Hettige, ¶ [0072], [0080]; FIG. 2); and responsive to user input identifying an accepted solution from the candidate solutions, updating a particular data source with the accepted solution (“The execution engine 250 implements the execution plan 210 by running each agent and executing each action in order based on the ordered list of agents and/or actions using the appropriate engine(s)” where “Over time, a library of generic end-user task or action types (e.g., semantic search, summarization, compare/contrast, heterogeneous data synthesis, etc.) may be built to ensure that the indices and models within the context and memory store 214 are optimized to the various task or action types.”; Hettige, ¶ [0072]). However, Hettige fails to expressly recite including instructions requesting that the generative language model generate constraint data structures representing the preferences according to a specified constraint data format; receiving, from the generative language model, the constraint data structures generated by the generative language model, the constraint data structures being in the specified constraint data format; parsing the constraint data structures generated by the generative language model to extract constraint parameters, the constraint parameters including constraint priorities generated by the generative language model; processing the constraint parameters with a constraint solver, wherein the constraint solver identifies candidate solutions that satisfy at least some of the constraint parameters, based at least on numerical weights representing the constraint priorities generated by the generative language model.
Ramamonjison teaches systems and methods for “extracting the meaning and formulation of an optimization problem based on its text description.” (Ramamonjison, ¶ Abstract). Regarding claim 1, Ramamonjison teaches generating constraint management prompts for a generative language model (“the baseline model is a BART encoder-decoder {generative language model}” that “leverages a prompt-guided generation and a copy mechanism to generate a meaning representation of the optimization formulation.” where formulating a “prompt-guided generation” process to output mathematical meaning representations is the generation of constraint management prompts.; Ramamonjison, ¶ p. 7, lines 5-11), the constraint management prompts being based on the natural language inputs (“They used the BART-large encoder-decoder model and enriched the input” which is the original problem description “by surrounding entities with XML-like tagging,” thus the input (constraint management prompt) is directly based on the initial natural language inputs.; Ramamonjison, ¶ p. 8, line 35-p. 9, line 5; p. 6, lines 5-6) and including instructions requesting that the generative language model generate constraint data structures representing the preferences according to a specified constraint data format (“The second task creates an intermediate representation of the linear programming (LP) problem that is converted into a format that can be used by commercial solvers” and “As shown in Figure 2, the meaning representation should be converted to a canonical form for evaluation,” where the intermediate meaning representation in the “canonical form {specified constraint data format}”, is a key-value JSON-style array (see Figure 2), which are constraint data structures representing the preferences.; Ramamonjison, ¶ p. 1, Abstract; p. 6, lines 8-11; Figure 2); inputting the constraint management prompts to the generative language model (“For the generation sub-task, the baseline model is a BART encoder-decoder...that leverages a prompt-guided generation and a copy mechanism to generate a meaning representation of the optimization formulation.”; Ramamonjison, ¶ p. 195, lines 1-8); receiving, from the generative language model, the constraint data structures generated by the generative language model (“The ground-truth label annotations consist of the objective declaration and the constraints declarations as shown in Figure 2” and the “output of the semantic parser is the meaning representation of those declarations,” where the semantic parser outputs the meaning representation, which is receiving the constraint data structures generated by the generative language model.; Ramamonjison, ¶ p. 6, lines 5-11), the constraint data structures being in the specified constraint data format (“As shown in Figure 2, the meaning representation should be converted to a canonical form for evaluation,” where the model’s output is structured in a highly specific meaning representation format (detailed in Figure 2 as dictionaries with keys like “type”, “limit”, “direction”, etc.) which allows conversion to algebraic arrays. As such, this structured meaning representation is the specified constraint data format.; Ramamonjison, ¶ p. 6, lines 8-11); parsing the constraint data structures generated by the generative language model to extract constraint parameters (“The starter kit for sub-task 2 contains code to parse the XML-like intermediate representations and annotated examples {parsing the intermediate representations}” into “our Problem Formulation dataclass,” as “an intermediate representation of the linear programming (LP) problem that is converted into a format that can be used by commercial solvers”; Ramamonjison, ¶ p. 7, lines 4-6; p. 1, Abstract); [and] processing the constraint parameters with a constraint solver (“converting optimization problems into a form that can be passed to commercial optimization solvers to efficiently find optimal solutions”; Ramamonjison, ¶ p. 2, lines 26-29).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the multi-task digital assistant input pipeline of Hettige to incorporate the teachings of Ramamonjison to include including instructions requesting that the generative language model generate constraint data structures representing the preferences according to a specified constraint data format; inputting the constraint management prompts to the generative language model; receiving, from the generative language model, the constraint data structures generated by the generative language model, the constraint data structures being in the specified constraint data format; parsing the constraint data structures generated by the generative language model to extract constraint parameters; [and] processing the constraint parameters with a constraint solver. Ramamonjison teaches prompting of a generative language model to act as a translator that extracts natural language constraints into a strict, canonical mathematical representation to be processed by an external, deterministic constraint solver, which would allow a POSITA to offload the rigid logical reasoning from the LLM to a dedicated mathematical solver, thus reducing logical errors and improving the reliability and accuracy of candidate solutions, as understood in light of the disclosure of Ramamonjison. (Ramamonjison, ¶ Abstract). However, Hettige and Ramamonjison fails to expressly recite wherein the constraint solver identifies candidate solutions that satisfy at least some of the constraint parameters based at least on numerical weights representing the constraint priorities generated by the generative language model.
Mitchell teaches utilizing a generative language model for assigning numerical weights (beliefs/probabilities) to constraints. (Mitchell, ¶ Abstract). Regarding claim 1, Mitchell teaches processing the constraint parameters with a constraint solver, (“We show that a weighted MaxSAT solver can efficiently compute high quality answer choices under this factor graph, improving over the raw model’s predictions,” where the factor graph, containing the constraints and beliefs is processed by a weighted MaxSAT solver {a constraint solver} to compute the answer choices {processing the constraint parameters}; Mitchell, ¶ p.754, Abstract) wherein the constraint solver identifies candidate solutions that satisfy at least some of the constraint parameters (The “weighted MaxSAT solver {the constraint solver}” computes “high quality answer choices {identifies candidate solutions} under this factor graph,” where the factor graph containing the constraints and beliefs is processed by a weighted MaxSAT solver {a constraint solver} to compute the answer choices, and analyze “the likelihood of each answer choice” with respect to the beliefs and constraints; Mitchell, ¶ p.754, Abstract) based at least on numerical weights representing the constraint priorities generated by the generative language model (discloses “a weighted MaxSAT solver” which evaluates parameters based on the assigned weights (as evidenced by, at least, the complement to the violation metric for computing consistency within batches, which indicates the relevance of constraint violation in a candidate solution is a function of the beliefs), “can efficiently compute high quality answer choices under this factor graph, improving over the raw model’s predictions,” where the factor graph “accounts for both the model’s belief about the likelihood of each answer choice in isolation and the NLI model’s beliefs about pair-wise answer choice compatibility.”; Mitchell, ¶ p.754, Abstract; p. 1759, lines 14-23).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the multi-task digital assistant input pipeline of Hettige, as modified by the natural language constraint translator of Ramamonjison, to incorporate the teachings of Mitchell to include wherein the constraint solver identifies candidate solutions that satisfy at least some of the constraint parameters based at least on numerical weights representing the constraint priorities generated by the generative language model. The system of Mitchell including the weighted MaxSAT solver can calculate a solution that satisfies the constraints by converting “soft” human preferences to numerical weights, which allows the system, such as the assistant of Hettige, to mathematically calculate the optimal compromise solution rather than failing when perfect satisfaction of all constraints is impossible, resulting in a more robust, flexible, and human-like planning agent, as understood in light of the disclosure of Mitchell. (Mitchell, ¶ Abstract).
Regarding claim 8, the rejection of claim 1 is incorporated. Hettige further discloses wherein the constraint management prompts specify a list of available constraint management actions for the generative language model to select from based on the natural language inputs received from the user (“one or more responses are generated for the one or more prompts. The one or more responses may be generated based on the action retriever prompt template (e.g., Table 1), or based on a response template” where the generated responses “may confirm a receipt of information in the prompt, update slots in the action plan, seek for missing information, and/or confirm an execution plan.” where, “The list of candidate agents and/or actions with associated metadata is appended to the utterance 202 and/or action performed by the user to construct an input prompt 227 for the LLM 216.” As such, the constraint management actions performed based on the response template is understood as based on available constraint management actions {e.g., a list}. Further, said actions are selected based on the natural language inputs received from the user {e.g., performing the function of confirming receipt of information in the prompt, etc.}.; Hettige, ¶ [0063], [0160]).
Regarding claim 19, Hettige discloses A computer-readable storage medium storing computer-readable instructions which, when executed by a processing unit, cause the processing unit to perform acts comprising (Systems and methods described with reference to a digital assistant, as implemented in a computing environment 200, where “The digital assistant 115A and its systems and subsystems may be implemented only in software (e.g., code, instructions stored on a computer-readable medium and executable by one or more processors)”; Hettige, ¶ [0055]): receiving natural language inputs from a user, the natural language inputs specifying preferences of the user in natural language (As described with reference to an example, “it is assumed that a user ‘David’ is interested in making a change to his 401k contribution, and in an utterance 202, David provides the following input: Hi, how are you, I want to make a change to my 401k contribution. The utterance 202 can be communicated to the digital assistant (e.g., via a digital assistant user interface such as a text dialogue box or microphone).”; Hettige, ¶ [0056]); generating constraint management prompts for a generative language model (“The list of candidate agents and/or actions with associated metadata is appended to the utterance 202 and/or action performed by the user to construct an input prompt 227 {constraint management prompts} for the LLM 216. {generative language model}”; Hettige, ¶ [0063]), the constraint management prompts being based on the natural language inputs (The input prompt 227 generated from the utterance 202, and thus is based on the utterance 202; Hettige, ¶ [0063]); inputting the constraint management prompts to the generative language model (The input prompt 227 is sent to the LLM 216 to be processed.; Hettige, ¶ [0063]); outputting the candidate solutions to the user (“the output pipeline 270 transmits the responses 272 to the end user such as via a user device or interface” which can include requesting information regarding alternative execution plans where “the LLM 236 generates another response 272 prompting the user for the missing information (Would you like to change your contribution by percentage or amount?[Percentage][Amount]).” Though referred to as “missing information”, it would be understood to one having ordinary skill in the art that, as this appears to occur after the generation of the execution plan 210, said missing information clearly does not result in failure to generate the “execution plan 210” in the described embodiment of para [0080]. As such, the missing information is understood as a selection between separate implementations resulting in separate execution plans 210, each of which is presented to the user “via the user device or interface” for selection and subsequent implementation based on said selection.; Hettige, ¶ [0072], [0080]; FIG. 2); and responsive to user input identifying an accepted solution from the candidate solutions, updating a particular data source with the accepted solution (“The execution engine 250 implements the execution plan 210 by running each agent and executing each action in order based on the ordered list of agents and/or actions using the appropriate engine(s)” where “Over time, a library of generic end-user task or action types (e.g., semantic search, summarization, compare/contrast, heterogeneous data synthesis, etc.) may be built to ensure that the indices and models within the context and memory store 214 are optimized to the various task or action types.”; Hettige, ¶ [0072]). However, Hettige fails to expressly recite including instructions requesting that the generative language model generate constraint data structures representing the preferences according to a specified constraint data format; receiving, from the generative language model, the constraint data structures generated by the generative language model, the constraint data structures being in the specified constraint data format; parsing the constraint data structures generated by the generative language model to extract constraint parameters, the constraint parameters including constraint priorities generated by the generative language model; processing the constraint parameters with a constraint solver, wherein the constraint solver identifies candidate solutions that satisfy at least some of the constraint parameters, based at least on numerical weights representing the constraint priorities generated by the generative language model.
The relevance of Ramamonjison is described above with relation to claim 1. Regarding claim 19, Ramamonjison teaches generating constraint management prompts for a generative language model (“the baseline model is a BART encoder-decoder {generative language model}” that “leverages a prompt-guided generation and a copy mechanism to generate a meaning representation of the optimization formulation.” where formulating a “prompt-guided generation” process to output mathematical meaning representations is the generation of constraint management prompts.; Ramamonjison, ¶ p. 7, lines 5-11), the constraint management prompts being based on the natural language inputs (“They used the BART-large encoder-decoder model and enriched the input” which is the original problem description “by surrounding entities with XML-like tagging,” thus the input (constraint management prompt) is directly based on the initial natural language inputs.; Ramamonjison, ¶ p. 8, line 35-p. 9, line 5; p. 6, lines 5-6) and including instructions requesting that the generative language model generate constraint data structures representing the preferences according to a specified constraint data format (“The second task creates an intermediate representation of the linear programming (LP) problem that is converted into a format that can be used by commercial solvers” and “As shown in Figure 2, the meaning representation should be converted to a canonical form for evaluation,” where the intermediate meaning representation in the “canonical form {specified constraint data format}”, is a key-value JSON-style array (see Figure 2), which are constraint data structures representing the preferences.; Ramamonjison, ¶ p. 1, Abstract; p. 6, lines 8-11; Figure 2); inputting the constraint management prompts to the generative language model (“For the generation sub-task, the baseline model is a BART encoder-decoder...that leverages a prompt-guided generation and a copy mechanism to generate a meaning representation of the optimization formulation.”; Ramamonjison, ¶ p. 195, lines 1-8); receiving, from the generative language model, the constraint data structures generated by the generative language model (“The ground-truth label annotations consist of the objective declaration and the constraints declarations as shown in Figure 2” and the “output of the semantic parser is the meaning representation of those declarations,” where the semantic parser outputs the meaning representation, which is receiving the constraint data structures generated by the generative language model.; Ramamonjison, ¶ p. 6, lines 5-11), the constraint data structures being in the specified constraint data format (“As shown in Figure 2, the meaning representation should be converted to a canonical form for evaluation,” where the model’s output is structured in a highly specific meaning representation format (detailed in Figure 2 as dictionaries with keys like “type”, “limit”, “direction”, etc.) which allows conversion to algebraic arrays. As such, this structured meaning representation is the specified constraint data format.; Ramamonjison, ¶ p. 6, lines 8-11); parsing the constraint data structures generated by the generative language model to extract constraint parameters (“The starter kit for sub-task 2 contains code to parse the XML-like intermediate representations and annotated examples {parsing the intermediate representations}” into “our Problem Formulation dataclass,” as “an intermediate representation of the linear programming (LP) problem that is converted into a format that can be used by commercial solvers”; Ramamonjison, ¶ p. 7, lines 4-6; p. 1, Abstract); [and] processing the constraint parameters with a constraint solver (“converting optimization problems into a form that can be passed to commercial optimization solvers to efficiently find optimal solutions”; Ramamonjison, ¶ p. 2, lines 26-29).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the multi-task digital assistant input pipeline of Hettige to incorporate the teachings of Ramamonjison to include including instructions requesting that the generative language model generate constraint data structures representing the preferences according to a specified constraint data format; inputting the constraint management prompts to the generative language model; receiving, from the generative language model, the constraint data structures generated by the generative language model, the constraint data structures being in the specified constraint data format; parsing the constraint data structures generated by the generative language model to extract constraint parameters; [and] processing the constraint parameters with a constraint solver. Ramamonjison teaches prompting of a generative language model to act as a translator that extracts natural language constraints into a strict, canonical mathematical representation to be processed by an external, deterministic constraint solver, which would allow a POSITA to offload the rigid logical reasoning from the LLM to a dedicated mathematical solver, thus reducing logical errors and improving the reliability and accuracy of candidate solutions, as understood in light of the disclosure of Ramamonjison. (Ramamonjison, ¶ Abstract). However, Hettige and Ramamonjison fails to expressly recite wherein the constraint solver identifies candidate solutions that satisfy at least some of the constraint parameters based at least on numerical weights representing the constraint priorities generated by the generative language model.
The relevance of Mitchell is described above with relation to claim 1. Regarding claim 19, Mitchell teaches processing the constraint parameters with a constraint solver, (“We show that a weighted MaxSAT solver can efficiently compute high quality answer choices under this factor graph, improving over the raw model’s predictions,” where the factor graph, containing the constraints and beliefs is processed by a weighted MaxSAT solver {a constraint solver} to compute the answer choices {processing the constraint parameters}; Mitchell, ¶ p.754, Abstract) wherein the constraint solver identifies candidate solutions that satisfy at least some of the constraint parameters (The “weighted MaxSAT solver {the constraint solver}” computes “high quality answer choices {identifies candidate solutions} under this factor graph,” where the factor graph containing the constraints and beliefs is processed by a weighted MaxSAT solver {a constraint solver} to compute the answer choices, and analyze “the likelihood of each answer choice” with respect to the beliefs and constraints; Mitchell, ¶ p.754, Abstract) based at least on numerical weights representing the constraint priorities generated by the generative language model (discloses “a weighted MaxSAT solver” which evaluates parameters based on the assigned weights (as evidenced by, at least, the complement to the violation metric for computing consistency within batches, which indicates the relevance of constraint violation in a candidate solution is a function of the beliefs), “can efficiently compute high quality answer choices under this factor graph, improving over the raw model’s predictions,” where the factor graph “accounts for both the model’s belief about the likelihood of each answer choice in isolation and the NLI model’s beliefs about pair-wise answer choice compatibility.”; Mitchell, ¶ p.754, Abstract; p. 1759, lines 14-23).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the multi-task digital assistant input pipeline of Hettige, as modified by the natural language constraint translator of Ramamonjison, to incorporate the teachings of Mitchell to include wherein the constraint solver identifies candidate solutions that satisfy at least some of the constraint parameters based at least on numerical weights representing the constraint priorities generated by the generative language model. The system of Mitchell including the weighted MaxSAT solver can calculate a solution that satisfies the constraints by converting “soft” human preferences to numerical weights, which allows the system, such as the assistant of Hettige, to mathematically calculate the optimal compromise solution rather than failing when perfect satisfaction of all constraints is impossible, resulting in a more robust, flexible, and human-like planning agent, as understood in light of the disclosure of Mitchell. (Mitchell, ¶ Abstract).
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige, Ramamonjison, and Mitchell as applied to claim(s) 1 above, and further in view of Patil.
Regarding claim 2, the rejection of claim 1 is incorporated. Hettige, Ramamonjison, and Mitchell disclose all of the elements of the current invention as stated above. Hettige further discloses further comprising: identifying available data sources to the generative language model (“the context and memory store 214 provides a searchable comprehensive record of the capabilities of all agents and associated assets that are available to the digital assistant for responding to the request.”; Hettige, ¶ [0060]). However, Hettige, Ramamonjison, and Mitchell fail to expressly recite providing data checking prompts to the generative language model, the data checking prompts instructing the generative language model to determine whether the constraint parameters can be checked given the available data sources.
Patil teaches systems and methods for generation and verification of API calls using an LLM. (Patil, ¶ [0015]). Regarding claim 2, Patil teaches further comprising: identifying available data sources to the generative language model (During inference, “the user provides the prompt in natural language (Fig: 3).” and the system “first retrieves the most up-to-date API documentation stored in the API Database”; Patil, ¶ p. 5, lines 17-27); and providing data checking prompts to the generative language model (The retrieved API documentation “is then concatenated to the user prompt along with the message Use this API documentation for reference: before feeding it to Gorilla.” where, by appending the system’s available tools to the user prompt, alongside the explicit command, forces the model to perform an evaluation against those tools before acting, which is providing data checking prompts to the generative language model.; Patil, ¶ p. 5, lines 17-27), the data checking prompts instructing the generative language model to determine whether the constraint parameters can be checked given the available data sources (Given the user prompt in natural language, Gorilla identifies and writes the most suitable API call where the system utilizes “AST [Abstract Syntax Tree] tree matching technique” to evaluate if the model accurately selected an API that matches the constraints without hallucinating an unavailable tool, where, instructing the generative language model to identify the correct API call from the provided documentation without hallucinating, is instructing the generative language model to determine whether the constraint parameters can be logically checked or fulfilled given the data sources.; Patil, ¶ p. 5, lines 29-53).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the multi-task digital assistant input pipeline of Hettige, as modified by the natural language constraint translator of Ramamonjison, and as modified by the constraint weighting of Mitchell, to incorporate the teachings of Patil to include providing data checking prompts to the generative language model, the data checking prompts instructing the generative language model to determine whether the constraint parameters can be checked given the available data sources. The actual API/data schema validation of Patil, as incorporated into the execution pipeline of a digital assistant can ensure the system only attempts to generate code or query backend data after mathematically confirming that available data sources possess the required parameters, which prevents the system from wasting computational resources on hallucinated tasks and ultimately prevents catastrophic execution errors, thereby improving the reliability and stability of the digital assistant, as understood in light of Patil. (Patil, ¶ Abstract).
Claim 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige, Ramamonjison, and Mitchell as applied to claim(s) 2 above, and further in view of Patil and Watson.
Regarding claim 3, the rejection of claim 2 is incorporated. Hettige, Ramamonjison, and Mitchell disclose all of the elements of the current invention as stated above. However, Hettige, Ramamonjison, and Mitchell fail to expressly recite further comprising: responsive to a response from the generative language model indicating that the constraint parameters can be checked given the available data sources, providing code generation prompts to the generative language model, the code generation prompts instructing the generative language model to generate constraint-checking source code that checks the constraint parameters; receiving the constraint-checking source code from the generative language model; and executing the constraint-checking source code generated by the generative language model to determine whether possible solutions meet the constraint parameters.
The relevance of Patil is described above with relation to claim 2. Regarding claim 3, Patil teaches further comprising: responsive to a response from the generative language model indicating that the constraint parameters can be checked given the available data sources, [providing an instruction] (Given the user prompt in natural language, Gorilla identifies and writes the most suitable API call where the system utilizes “AST [Abstract Syntax Tree] tree matching technique” to evaluate if the model accurately selected an API that matches the constraints, where in the proposed combined system, the language model successfully identifying and outputting the validated API call acts as the response indicating the constraint parameters can be checked given the available data sources, where the logical end result of determining and validating that the constraint parameters can be checked given the available data sources (as taught by Patil) is to instruct the system to actually generate the functional code.; Patil, ¶ p. 5, lines 29-53).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the multi-task digital assistant input pipeline of Hettige, as modified by the natural language constraint translator of Ramamonjison, and as modified by the constraint weighting of Mitchell, to incorporate the teachings of Patil to include further comprising: responsive to a response from the generative language model indicating that the constraint parameters can be checked given the available data sources, [providing an instruction]. The actual API/data schema validation of Patil, as incorporated into the execution pipeline of a digital assistant can ensure the system only attempts to generate code or query backend data after mathematically confirming that available data sources possess the required parameters, which prevents the system from wasting computational resources on hallucinated tasks and ultimately prevents catastrophic execution errors, thereby improving the reliability and stability of the digital assistant, as understood in light of Patil. (Patil, ¶ Abstract). However, Hettige, Ramamonjison, Mitchell, and Patil, fail to expressly recite providing code generation prompts to the generative language model, the code generation prompts instructing the generative language model to generate constraint-checking source code that checks the constraint parameters; receiving the constraint-checking source code from the generative language model; and executing the constraint-checking source code generated by the generative language model to determine whether possible solutions meet the constraint parameters.
Watson teaches “methods and systems for using a large language model to generate executable code” with controlled data access. (Watson, ¶ [0002]). Regarding claim 3, Watson teaches providing code generation prompts to the generative language model (“A query is supplied to the context to create a full prompt” and “the context is fed into the LLM, which generates the code” where feeding a prompt that explicitly requests the creation of an executable Python code (e.g., from FIG. 6, “Rewritten query with guidance: Write python code to answer...”) constitutes providing code generation prompts to the generative language model.; Watson, ¶ [0082]-[0083], FIG. 6), the code generation prompts instructing the generative language model to generate constraint-checking source code that checks the constraint parameters (“As explained with reference to an example in FIG. 7, “additional instructions to: 1. Must by python code 2 Must answer user’s original question 3. Must build code from a table named df in memory” which requires answering the user’s original question against a specific data table where the answer is written in python code, where the limit as defined in the user query (such as a date cutoff)constitutes user’s constraint parameters. Because the generative language model is instructed to write python code that mathematically evaluates the data against these specific limits (e.g., executing a Boolean filter to check if a fund date is <2021), the prompt is instructing the generative language model to generate constraint-checking code that checks the constraint parameters.; Watson, ¶ [0082]-[0083], [0087], FIG. 7); receiving the constraint-checking source code from the generative language model (“By providing the description of the data, instructions to follow, and a query for the data, the system can create executable code capable of producing interactive and dynamic outputs in a variety of styles.”; Watson, ¶ [0085]); and executing the constraint-checking source code generated by the generative language model to determine whether possible solutions meet the constraint parameters (“This code can be executed in a programming environment to dynamically generate content, such as tables or sunburst charts,” where running this code to filter data tables and isolate only the entries that satisfy the user’s query is the executing of the constraint checking code, which is generated by the generative language model, to determine whether possible solutions meet the constraint parameters.; Watson, ¶ [0083]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the multi-task digital assistant input pipeline of Hettige, as modified by the natural language constraint translator of Ramamonjison, as modified by the constraint weighting of Mitchell, and as taught by the prompt-level schema validation of Patil, to incorporate the teachings of Watson to include providing code generation prompts to the generative language model, the code generation prompts instructing the generative language model to generate constraint-checking source code that checks the constraint parameters; receiving the constraint-checking source code from the generative language model; and executing the constraint-checking source code generated by the generative language model to determine whether possible solutions meet the constraint parameters. Watson discloses systems and methods for using “a large language model to generate executable code in a manner that preserves privacy and confidentiality of proprietary data,” which provides the known benefit allowing the ease and convenience of generative model use for generating answers to complex questions, while simultaneously protecting sensitive, personal, and/or proprietary information, as recognized by Watson. (Watson, ¶ [0005]-[0006]).
Claims 9-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hettige, Ramamonjison, and Mitchell as applied to claim 8 above, and further in view of Cohen.
Regarding claim 9, the rejection of claim 8 is incorporated. Hettige, Ramamonjison, and Mitchell disclose all of the elements of the current invention as stated above. Hettige further discloses wherein the list of available constraint management actions includes [changing]... a constraint, messaging the user, and generating a new candidate solution (discloses constraint management actions such as “update slots in the action plan, seek for missing information, and/or confirm an execution plan.” where, “The list of candidate agents and/or actions with associated metadata is appended to the utterance 202 and/or action performed by the user to construct an input prompt 227 for the LLM 216.” As such, the constraint management actions performed based on the response template is part of “the list of candidate...actions” based on available constraint management actions. Further, said actions are selected based on the natural language inputs received from the user {e.g., performing the function of confirming receipt of information in the prompt, etc.}.; Hettige, ¶ [0063], [0160]). However, Hettige, Ramamonjison, and Mitchell fail to expressly recite wherein the list of available constraint management actions includes adding a new constraint, changing priority of an existing constraint, deleting a constraint, messaging the user, and generating a new candidate solution.
The relevance of Cohen is described above with relation to claim 7. Regarding claim 9, Cohen teaches wherein the list of available constraint management actions includes adding a new constraint, changing priority of an existing constraint, deleting a constraint, messaging the user, and generating a new candidate solution (using the domain specific constraints, “general-purpose domain-independent algorithms can be used to draw inferences for both intent disambiguation and constraint propagation” where the system includes allowing “the posting {adding a new constraint}, modification {changing...an existing constraint}, or retraction of a constraint {deleting a constraint}” based on interpretation of the user utterance, and the system can further evaluate the constraints comparatively, where actions performed can include the identification and presentation of “minimal cost alternative” by the system, which can be offered to the user to accept or modify {messaging the user, and generating a new candidate solution} and further, the system can, in light of unresolvable conflict, “suggest relaxing... constraints to the user. {changing priority of an existing constraint}”; Cohen, ¶ [0071]-[0074]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the multi-task digital assistant input pipeline of Hettige, as modified by the natural language constraint translator of Ramamonjison, and as modified by the constraint weighting of Mitchell, to incorporate the teachings of Cohen to include wherein the list of available constraint management actions includes adding a new constraint, changing priority of an existing constraint, deleting a constraint, messaging the user, and generating a new candidate solution. Cohen discloses the determination of explicit and implicit constraints from the user utterance and “general-purpose domain-independent algorithms can be used to draw inferences for both intent disambiguation and constraint propagation,” where the “underlying engine can also handle soft constraints, in cases where the constraint may be violated for some cost or in cases where there are different degrees of violations,” thus allowing for differential treatment of constraints based on importance and priority, which better captures the user intent in satisfying the described constraints, as recognized by Cohen. (Cohen, ¶ [0005]-[0006]).
Regarding claim 10, the rejection of claim 9 is incorporated. Hettige, Ramamonjison, Mitchell, and Cohen disclose all of the elements of the current invention as stated above. Hettige further discloses wherein the constraint management prompts include examples of the available constraint management actions and the specified constraint data format (“The optional content enhancement module 438 uses machine learning models to enrich the response generated by the response generation module 436 with relevant details, examples, explanations, and additional context. For example, the ML models used by the optional content enhancement module 438 can break down complex concepts into detailed, easy-to-understand explanations, use specific examples to illustrate points more clearly, include relevant statistics or data to support the information, and/or anticipate follow-up prompts or responses. “; Hettige, ¶ [0188]).
Regarding claim 11, the rejection of claim 10 is incorporated. Hettige, Ramamonjison, Mitchell, and Cohen disclose all of the elements of the current invention as stated above. Hettige further discloses further comprising: generating the constraint management prompts from a template having the examples of the available constraint management actions (“The list of candidate agents and/or actions with associated metadata is appended to the utterance 202 and/or action performed by the user to construct an input prompt 227 {constraint management prompts} for the LLM 216. {generative language model}” where “Rule-based approaches can additionally or alternatively be used to synthesize data” and “fixed templates with placeholders can be used to create various dialogue scenarios.”; Hettige, ¶ [0063], [0100]).
Regarding claim 12, the rejection of claim 11 is incorporated. Hettige, Ramamonjison, Mitchell, and Cohen disclose all of the elements of the current invention as stated above. Hettige further discloses further comprising: including, in the constraint management prompts, a conversation history with the user (“conversation context 229 concerning the utterance 202 are additionally appended to the list of candidate agents and the utterance 202. The conversation context 229 can be retrievable from one or more sources including the context and memory store 214, and includes user session information, dialog state, conversation or contextual history, application context, page context, user information, or any combination thereof.”; Hettige, ¶ [0065]).
Regarding claim 13, the rejection of claim 12 is incorporated. Hettige, Ramamonjison, Mitchell, and Cohen disclose all of the elements of the current invention as stated above. Hettige further discloses further comprising: including, in the constraint management prompts, a list of previously-generated constraints (“conversation context 229 concerning the utterance 202 are additionally appended to the list of candidate agents and the utterance 202. The conversation context 229 can be retrievable from one or more sources including the context and memory store 214, and includes user session information, dialog state, conversation or contextual history, [and] application context... {a list of previously generated constraints}”; Hettige, ¶ [0065]).
Allowable Subject Matter
Claims 4-7 and 20 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.
The following is an examiner’s statement of reasons for indicating allowable subject matter:
Regarding claim 4, the rejection of claim 3 is incorporated. Hettige, Ramamonjison, Mitchell, Patil, and Watson disclose all of the elements of the current invention as stated above. However, Hettige, Ramamonjison, Mitchell, Patil, and Watson fail to teach or suggest at least “wherein the executing comprises invoking the constraint-checking source code by the constraint solver.”
Regarding claim 20, the rejection of claim 19 is incorporated. Hettige, Ramamonjison, Mitchell, Patil, and Watson disclose all of the elements of the current invention as stated above. The closest prior art of record Watson further teaches the acts further comprising: generating code generation prompts for the generative language model (“A query is supplied to the context to create a full prompt” and “the context is fed into the LLM, which generates the code” where feeding a prompt that explicitly requests the creation of an executable Python code (e.g., from FIG. 6, “Rewritten query with guidance: Write python code to answer...”) constitutes generating code generation prompts for the generative language model.; Watson, ¶ [0082]-[0083], FIG. 6), the code generation prompts instructing the generative language model to generate constraint-checking source code that checks whether possible solutions satisfy the constraint parameters (“As explained with reference to an example in FIG. 7, “additional instructions to: 1. Must by python code 2 Must answer user’s original question 3. Must build code from a table named df in memory” which requires answering the user’s original question against a specific data table where the answer is written in python code, where the limit as defined in the user query (such as a date cutoff)constitutes user’s constraint parameters. Because the generative language model is instructed to write python code that mathematically evaluates the data against these specific limits (e.g., executing a Boolean filter to check if a fund date is <2021), the prompt is instructing the generative language model to generate constraint-checking code that checks the constraint parameters.; Watson, ¶ [0082]-[0083], [0087], FIG. 7); receiving the constraint-checking source code from the generative language model (“By providing the description of the data, instructions to follow, and a query for the data, the system can create executable code capable of producing interactive and dynamic outputs in a variety of styles.”; Watson, ¶ [0085]); and executing the constraint-checking source code… to identify the candidate solutions (“This code can be executed in a programming environment to dynamically generate content, such as tables or sunburst charts,” where running this code to filter data tables and isolate only the entries that satisfy the user’s query is the executing of the constraint checking code, which is generated by the generative language model, to determine whether possible solutions meet the constraint parameters.; Watson, ¶ [0083]). However, Hettige, Ramamonjison, Mitchell, Patil, and Watson fail to teach or suggest at least “executing the constraint-checking source code with the constraint solver.”
Regarding claims 4 and 20, the limitation of “invoking the constraint-checking source code by the constraint solver,” or “executing the constraint-checking source code with the constraint solver,” in light of all remaining and intervening limitations, is not taught by the prior art of record. With regards to the cited references, Hettige and Ramamonjison are silent regarding this limitation. Mitchell, as explained above, teaches the use of a constraint solver (e.g., a weighted MatSAT solver) but said parameters and priorities are not in the form of a constraint checking source code. In Mitchell, the MatSAT solver evaluates Boolean satisfiability formulas and numerical probabilities. Mitchell does not parse, compile or otherwise invoke executable “source code” to perform the checks. Watson teaches the generation of constraint checking source code to verify that constraints are met, but this constraint checking source code is not processed by the constraint solver. Watson explicitly teaches having the LLM write functional Python code to filter data. However, Watson executes this code in a standard programming environment. Watson does not teach or reasonably suggest using a mathematical “constraint solver” optimization engine to invoke or process that code. Patil fails based both on order of operations (the system does not iteratively invoke the generated source code) and lack of disclosure of a constraint solver (an AST syntax matcher is not understood as a constraint solver in the context of the claim as amended). Therefore, Hettige, Ramamonjison, Mitchell, Patil, and Watson fail to teach or suggest all limitations of claim 4. The remaining art of record fails to cure these deficiencies.
Regarding claims 5-7, claims 5-7 depend from claim 4 and incorporate all limitations therefrom. Therefore, claims 5-7 are allowable for at least the same reasons as claim 4.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Reasons for Allowance
Claims 14-18 are allowed.
The following is an examiner’s statement of reasons for allowance:
Regarding claim 14, the closest prior art of record Hettige teaches A system comprising: a hardware processing unit; and a storage resource storing computer-readable instructions which, when executed by the hardware processing unit, cause the system to (Systems and methods described with reference to a digital assistant, as implemented in a computing environment 200, where “The digital assistant 115A and its systems and subsystems may be implemented only in software (e.g., code, instructions stored on a computer-readable medium and executable by one or more processors)”; Hettige, ¶ [0055]): receive natural language inputs from a user, the natural language inputs specifying preferences of the user in natural language (As described with reference to an example, “it is assumed that a user ‘David’ is interested in making a change to his 401k contribution, and in an utterance 202, David provides the following input: Hi, how are you, I want to make a change to my 401k contribution. The utterance 202 can be communicated to the digital assistant (e.g., via a digital assistant user interface such as a text dialogue box or microphone).”; Hettige, ¶ [0056]); generate constraint management prompts for a generative language model (“The list of candidate agents and/or actions with associated metadata is appended to the utterance 202 and/or action performed by the user to construct an input prompt 227 {constraint management prompts} for the LLM 216. {generative language model}”; Hettige, ¶ [0063]), the constraint management prompts being based on the natural language inputs (The input prompt 227 generated from the utterance 202, and thus is based on the utterance 202; Hettige, ¶ [0063]), output the candidate solutions to the user (“the output pipeline 270 transmits the responses 272 to the end user such as via a user device or interface” which can include requesting information regarding alternative execution plans where “the LLM 236 generates another response 272 prompting the user for the missing information (Would you like to change your contribution by percentage or amount?[Percentage][Amount]).” Though referred to as “missing information”, it would be understood to one having ordinary skill in the art that, as this appears to occur after the generation of the execution plan 210, said missing information clearly does not result in failure to generate the “execution plan 210” in the described embodiment of para [0080]. As such, the missing information is understood as a selection between separate implementations resulting in separate execution plans 210, each of which is presented to the user “via the user device or interface” for selection and subsequent implementation based on said selection.; Hettige, ¶ [0072], [0080]; FIG. 2); and responsive to user input identifying an accepted solution from the candidate solutions, update a particular data source with the accepted solution (“The execution engine 250 implements the execution plan 210 by running each agent and executing each action in order based on the ordered list of agents and/or actions using the appropriate engine(s)” where “Over time, a library of generic end-user task or action types (e.g., semantic search, summarization, compare/contrast, heterogeneous data synthesis, etc.) may be built to ensure that the indices and models within the context and memory store 214 are optimized to the various task or action types.”; Hettige, ¶ [0072]). However, Hettige does not specifically teach the remaining limitations of claim 14.
Ramamonjison does teach generate constraint management prompts for a generative language model (“the baseline model is a BART encoder-decoder {generative language model}” that “leverages a prompt-guided generation and a copy mechanism to generate a meaning representation of the optimization formulation.” where formulating a “prompt-guided generation” process to output mathematical meaning representations is the generation of constraint management prompts.; Ramamonjison, ¶ p. 7, lines 5-11), the constraint management prompts being based on the natural language inputs (“They used the BART-large encoder-decoder model and enriched the input” which is the original problem description “by surrounding entities with XML-like tagging,” thus the input (constraint management prompt) is directly based on the initial natural language inputs.; Ramamonjison, ¶ p. 8, line 35-p. 9, line 5; p. 6, lines 5-6) and including instructions requesting that the generative language model generate constraint data structures having constraint parameters representing the preferences of the user (“The second task creates an intermediate representation of the linear programming (LP) problem that is converted into a format that can be used by commercial solvers” and “As shown in Figure 2, the meaning representation should be converted to a canonical form for evaluation,” where the intermediate meaning representation in the “canonical form {specified constraint data format}”, is a key-value JSON-style array (see Figure 2), which are constraint data structures having constraint parameters representing the preferences.; Ramamonjison, ¶ p. 1, Abstract; p. 6, lines 8-11; Figure 2); receive the constraint data structures from the generative language model (“The ground-truth label annotations consist of the objective declaration and the constraints declarations as shown in Figure 2” and the “output of the semantic parser is the meaning representation of those declarations,” where the semantic parser outputs the meaning representation, which is receiving the constraint data structures generated by the generative language model.; Ramamonjison, ¶ p. 6, lines 5-11).
Mitchell does teach the constraint parameters including constraint priorities generated by the generative language model (“Given a batch of test inputs, ConCoRD samples several candidate outputs for each input and instantiates a factor graph that accounts for both the model’s belief about the likelihood of each answer choice in isolation and the NLI model’s beliefs about pair-wise answer choice compatibility,” where the beliefs (which act as probabilities of compatibility) are the constraint priorities generated by the “natural language inference (NLI) models {generative language model}”; Mitchell, ¶ p.754, Abstract) based at least on numerical weights representing the constraint priorities generated by the generative language model (discloses “a weighted MaxSAT solver” which evaluates parameters based on the assigned weights (as evidenced by, at least, the complement to the violation metric for computing consistency within batches, which indicates the relevance of constraint violation in a candidate solution is a function of the beliefs), “can efficiently compute high quality answer choices under this factor graph, improving over the raw model’s predictions,” where the factor graph “accounts for both the model’s belief about the likelihood of each answer choice in isolation and the NLI model’s beliefs about pair-wise answer choice compatibility.”; Mitchell, ¶ p.754, Abstract; p. 1759, lines 14-23).
Watson does teach generate code generation prompts for the generative language model (“A query is supplied to the context to create a full prompt” and “the context is fed into the LLM, which generates the code” where feeding a prompt that explicitly requests the creation of an executable Python code (e.g., from FIG. 6, “Rewritten query with guidance: Write python code to answer...”) constitutes providing code generation prompts to the generative language model.; Watson, ¶ [0082]-[0083], FIG. 6), the code generation prompts instructing the generative language model to generate constraint-checking source code that checks whether possible solutions satisfy the constraint parameters (“As explained with reference to an example in FIG. 7, “additional instructions to: 1. Must by python code 2 Must answer user’s original question 3. Must build code from a table named df in memory” which requires answering the user’s original question against a specific data table where the answer is written in python code, where the limit as defined in the user query (such as a date cutoff)constitutes user’s constraint parameters. Because the generative language model is instructed to write python code that mathematically evaluates the data against these specific limits (e.g., executing a Boolean filter to check if a fund date is <2021), the prompt is instructing the generative language model to generate constraint-checking code that checks the constraint parameters.; Watson, ¶ [0082]-[0083], [0087], FIG. 7); receive the constraint-checking source code from the generative language model (“By providing the description of the data, instructions to follow, and a query for the data, the system can create executable code capable of producing interactive and dynamic outputs in a variety of styles,” which, in the context of the ; Watson, ¶ [0085]); execute the constraint-checking source code… to identify candidate solutions that satisfy at least some of the constraint parameters (“This code can be executed in a programming environment to dynamically generate content, such as tables or sunburst charts,” where running this code to filter data tables and isolate only the entries that satisfy the user’s query is the executing of the constraint checking code, which is generated by the generative language model, to determine whether possible solutions meet the constraint parameters.; Watson, ¶ [0083])
However, none of the prior art references of record, either alone or in combination, teaches, suggests, or makes obvious the combination of limitations as recited in the independent claims.
More specifically, the limitation of “invoking the constraint-checking source code by the constraint solver,” in light of all remaining and intervening limitations, is not taught by the prior art of record. With regards to the cited references, Hettige and Ramamonjison are silent regarding this limitation. Mitchell, as explained above, teaches the use of a constraint solver (e.g., a weighted MatSAT solver) but said parameters and priorities are not in the form of a constraint checking source code. In Mitchell, the MatSAT solver evaluates Boolean satisfiability formulas and numerical probabilities. Mitchell does not parse, compile or otherwise invoke executable “source code” to perform the checks. Watson teaches the generation of constraint checking source code to verify that constraints are met, but this constraint checking source code is not processed by the constraint solver. Watson explicitly teaches having the LLM write functional Python code to filter data. However, Watson executes this code in a standard programming environment. Watson does not teach or reasonably suggest using a mathematical “constraint solver” optimization engine to invoke or process that code. Patil fails based both on order of operations (the system does not iteratively invoke the generated source code) and lack of disclosure of a constraint solver (an AST syntax matcher is not understood as a constraint solver in the context of the claim as amended). Therefore, Hettige, Ramamonjison, Mitchell, Patil, and Watson fail to teach or suggest all limitations of claim 14. The remaining art of record fails to cure these deficiencies.
Regarding claims 15-18, claims 15-18 depend from claim 14 and incorporate all limitations therefrom. Therefore, claims 15-18 are allowed for at least the same reasons as independent claim 14.
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.”
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Sean E. Serraguard whose telephone number is (313)446-6627. The examiner can normally be reached 07:00-17:00 M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Daniel C. Washburn can be reached at (571) 272-5551. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/Sean E Serraguard/Primary Examiner, Art Unit 2657
Prosecution Insights