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 .
DETAILED ACTION
The instant application having Application No. 18/679,817 filed on 5/31/2024 is presented for examination.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Drawings
The applicant’s drawings submitted are acceptable for examination purposes.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submissions of the Information Disclosure Statement dated 2/17/2026 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
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-4 and 11-18 are rejected under 35 U.S.C. 103 as being unpatentable over Miller (US 20240289545) in view of Raghu (US 20170235599).
As per claim 1, Miller discloses a computer implemented method for executing complex computing tasks in a computing platform (Abstract), the method comprising:
receiving, by a planning agent, a use case input indicating an objective for completion in the computing platform (Paragraph 6 “Disclosed is a system for creating solution plans to solve problems in an AI system. An example system includes a large language model (LLM), a plan creation component, a plan working memory, and a plan execution component. The plan creation component leverages the power of the LLM to break problems into sets of discrete tasks, or solution plans, which are stored in the plan working memory. As each step of a solution plan is executed by the plan execution component, results are captured in the plan working memory so that the last executed step is captured. The working memory operates in the background of the AI system to ensure that the discrete tasks are executed, managed, and tracked until a complete solution is realized. The self-maintained working memory topology provides a solution to problems areas often encountered in conventional stateless AI system that encounter token limits in problem solving.”);
decomposing, by the planning agent, the use case input into a plurality of tasks for achieving the objective (Paragraph 10 “In still other examples, the presently described systems and methods are able to efficiently aggregate multiple long inputs in the execution of a task, while ensuring that the prompts for executing individual steps are properly sized to avoid token and buffer limits. In yet another example, the presently described systems and methods are able to employ a working memory component in the plans created and executed by the LLM, providing for a more dynamic and adaptive solution space as the memory can grow and evolve as the LLM takes steps to execute the plan. Additionally, the presently described systems and methods are able to plan and execute control flow logic like conditionals and loops, significantly increases the capabilities regarding plan creation and execution.”);
providing, by the planning agent, each of the plurality of tasks to a respective task agent for execution (Paragraph 32 “In some examples, a chat prompt may be engineered such that the model not only emits conversational responses that are shown to the user, but also may provide inline instructions or actions such as one or more plan steps, code, or combinations thereof. The code may be written to invoke skills associated with the LLM. The code may also call APIs or leverage other resources to provide whatever the AI requires to complete the plan (e.g., place orders for bananas with Instacart, look up the latest Manchester United scores, etc.). An agent working with the AI may then simply carry out these instructions (e.g., execute the code by calling skills). The results of code execution may be injected into the next iteration with the AI. Working memory may also be injected by the orchestrator (the user or the AI depending on the implementation), leveraging all available things (e.g., resources, skills, information, data, etc.) that are semantically relevant to the discussion at hand with the AI such as past conversation history, additional memory, and results of execution of any code/instructions that the AI had previously returned.”).
Miller does not expressly disclose but Raghu discloses for each task of the plurality of tasks:
identifying, by the respective task agent, based on the task, a tool suitable for performing the task from a plurality of tools (Paragraph 21 “The conversation-based software development program 101 may generate a result program 216 by processing the substeps 206. At each substep 207, the conversation-based software development program 101 may generate a list of candidate APIs 208 from the API library 106. Where more than one API will work, the conversation-based software development program 101 may conversationally refine the candidate APIs by asking the developer 114 to further specify needs and preferences. In the Bangalore-Delhi example, the conversation-based software development program may identify, for the steps F1-F4, APIs that provide flight search and filtering functionality, and it may come up with four candidates: WeGo Flights API, QPX Express API, Clear Trip API, and Travel Fusion API. Each of these APIs has different features and functionality, and the conversation-based software development program 101 may reach a choice of a selected API 210 or a combination of selected APIs 210 that is/are sufficient to complete the particular sub step 207 by asking the developer questions that are directed to choosing among the features of the various candidate APIs 208. The conversation-based software development program 101 may repeat the API narrowing process separately for step T, booking the flight, and use a different API or combination of APIs.”); and
using the identified tool to execute an operation corresponding to the respective task in the computing platform (Paragraph 22 “Based on determining the selected API 210 or combination of APIs 210 for the particular substep 207, the conversation-based software development program 101 may generate the correct API calls 212 that complete the particular substep 207, and append the API calls 212 to the result program 116. The result program 116 may then be run by the developer 114, packaged for distribution, or otherwise used. A possible advantage that may be present in various embodiment of the present invention (though not required for the practice of the invention) is that the result program 116 can mix and match APIs between and within substeps 206 because each substep 206 may have its own API evaluation. This may enable the conversation-based software development program 101 to overcome a major limitation with API use, which is the developer's familiarity with various APIs and alternatives.”).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Miller to include the teachings of Raghu because selecting on an API library to implement the task allows for greater code reuse and simplification. In this way, the combination benefits by allowing different software libraries to be connected to order to more efficiently perform the task.
As per claim 2, Miller further discloses wherein the planning agent is coupled to a first large language model (Abstract),
wherein the planning agent generates a use case prompt by combining the use case input with planning context information based on a planning prompt template (Paragraph 6 “Disclosed is a system for creating solution plans to solve problems in an AI system. An example system includes a large language model (LLM), a plan creation component, a plan working memory, and a plan execution component. The plan creation component leverages the power of the LLM to break problems into sets of discrete tasks, or solution plans, which are stored in the plan working memory. As each step of a solution plan is executed by the plan execution component, results are captured in the plan working memory so that the last executed step is captured. The working memory operates in the background of the AI system to ensure that the discrete tasks are executed, managed, and tracked until a complete solution is realized. The self-maintained working memory topology provides a solution to problems areas often encountered in conventional stateless AI system that encounter token limits in problem solving.”);
wherein the planning agent provides the use case prompt to the first large language model (Paragraph 8 “receive an initial user prompt by a plan creation component of the AI system; “); and
wherein the first large language model provides the plurality of tasks for achieving the objective to the planning agent in response to the use case prompt (Paragraph 8 “build a goal based on the initial user prompt by the plan creation component of the AI system; generate solution plan based on the initial goal and the initial user prompt by the plan creation component of the AI system, wherein the plan creation component uses a large language mode (LLM) to generate a set of discrete steps for the solution plan to achieve the goal; store the solution plan, the user prompt, and the goal in a plan working memory of the AI system; and send a message to the user that is based on one or more of the solution plan and the goal.”).
As per claim 3, Miller further discloses wherein:
the use case input comprises a natural language description of the objective for completion in the computing platform (Paragraph 9 “Additionally, the user may provide user prompts to the AI system which may include a collection of individual requests, queries and other text (e.g., a paragraph of content), where the AI system may process such complex user provided inputs to develop complete solution plans that are ready for execution by a plan creation component of the AI system, or for user review before execution.”);, and
the planning context information comprises:
a description of a plurality of task types that can be performed on the computing platform (Paragraph 48 “Additionally, the LLM may be leveraged to identify a goal 154 for a problem to be solved, which may then be submitted to the plan creation component 150. The plan creation component 150 may process the goal and devise a solution plan 154. In otherwords, a new solution plan 154 may be formulated by the plan creation component 150 to solve the newly identified goal from the LLM 130. As described herein, the new solution plan 154 may include access to any registered functions or other resources of the LLM 130, as well be able to execute control flow logic such as conditionals and loops as part of the solution plan 156. Since the solution plans 156 are dynamic, or changing, based on the prompts 112, static plans need not be adhered to, providing improved functionality and problem solving. “); and
an indication that a first computing model should provide as an output a series of tasks required to complete the objective described in the use case input and that each task must belong to one of the plurality of task types (Paragraph 63).
As per claim 4, Miller further disc wherein the plurality of task types includes at least one selected from a group consisting of: a data integration task, a pipeline builder task, an object type task, an object link task, and an object action task (Paragraph 63).
As per claim 11, Miller further discloses further comprising:
determining, by the planning agent, that further information is required for execution of one or more tasks of the plurality of tasks (Paragraph 87 “At block 410B, “Receiving a User Prompt from Computing Device by a Plan Creation Component”, a prompt from a user (e.g., 112) may be received by the plan creation component (e.g., 150) for processing. The user prompt may again correspond to a single natural language string or sentence that presents one or more of a question, an instruction, an example, or data. In other examples, the user prompt may include cascaded sets of strings or sentences. In still other examples, the user prompt may include a combination of question, instruction, example and/or data that may be helpful in performing a task. In yet further examples, the user prompt may include details about stylistic choices for images, writing, or presentation of results Block 410B may be followed by block 420.”);
providing, by the planning agent, a user prompt to a user device requesting a user input indicating the required further information (Paragraph 87); and
receiving the user input including the required further information (Paragraph 87), wherein
providing the one or more tasks to a respective task agent for execution is performed based on receiving the user input (Paragraph 87).
As per claim 12, Miller further discloses further comprising:
determining that one or more tasks of the plurality of tasks includes a prohibited action; and preventing the one or more tasks from being executed (Paragraph 120).
As per claim 13, Miller further discloses further comprising:
updating the planning prompt template to include a description of a new type of task (Paragraph 79 “At block 420, “Building or Updating a Goal Based on the User Prompt by the Plan Creation Component”, a goal may be created by the plan creation component (e.g., 150) based on the received user prompt (e.g., 112). The user prompts may be provided in any form, from simple to complex. An example simple prompt may be a single question in a short phrase or sentence. An example complex prompt may be either multiple phrases or sentences combined together or in succession to one another. In still other examples, the user prompt may include manual definitions embedded therein such as previously described. After the plan creation component (e.g., 150) receives the user prompt, whether simple or complex, the plan creation component may leverage a large language mode (e.g., 130) to analyze and determine the semantic meaning of the phrases and identify a goal (e.g., 154). If a prior goal exists within the determined semantic meaning of a successively received prompt, the plan creation component (e.g., 150) may update, revise, or replace the goal. Block 420 may be followed by block 430.”); and
updating the task prompt template to provide a description of a new tool (Paragraph 79).
As per claim 14, it is a medium claim having similar limitations as cited in claim 1 and is thus rejected under the same rationale.
As per claim 15, it is an apparatus claim having similar limitations as cited in claim 1 and is thus rejected under the same rationale.
As per claim 16, it is an apparatus claim having similar limitations as cited in claim 2 and is thus rejected under the same rationale.
As per claim 17, it is an apparatus claim having similar limitations as cited in claim 3 and is thus rejected under the same rationale.
As per claim 18, it is an apparatus claim having similar limitations as cited in claim 4 and is thus rejected under the same rationale.
Claims 5, 6, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Miller in view of Raghu in further view of Cai (US 20230112921)
As per claim 5, Miller does not expressly disclose but Cai discloses
wherein each task agent is coupled to a second large language model (Paragraph 61 “Example techniques provided herein enable a user to generate or use a model chain. Chaining models can include or result from the process of breaking up complex tasks into smaller steps, where each step can be completed by an independent run of a model instantiation, and where the output of one step is used as input for the next. As a result of accumulating the gains across multiple runs, model chains can solve tasks that would be difficult for a single model (e.g., a single LLM) to perform in a single run. Thus, LLM Chaining is particularly beneficial for tasks that are challenging for an LLM to complete in a single pass but can be easier to accomplish through a series of smaller tasks that an LLM performs well.”);
wherein each task agent generates a respective task prompt by combining the task with task context information based on a task prompt template (Paragraph 13 “the respective prompt to each model instantiation in the model chain is user-selectable from a number of pre-defined template prompts that correspond to primitive subtasks.”);, and
wherein each task agent provides the respective task prompt to the second large language model (Paragraph 43 “Chaining can help users accomplish complex tasks with language models (e.g., LLMs) in a way that is more transparent and debuggable. In some examples, chaining takes advantage of LLMs' unique ability to handle a variety of independent tasks (e.g., defined via prompts). In a chain, a problem can be broken down into a number of smaller sub-tasks, each mapped to a distinct step with a corresponding prompt; results of one or more previous steps can be aggregated in the next step's input prompt. Thus, chaining enables users to run one or more language models (e.g., in some cases the same LLM) on multiple sub-tasks, with each sub-task having a higher probability of success (e.g., as opposed to solving the entire task in one go).”).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Miller as modified to include the teachings of Cai because it allows multiple LLMs to work together to solve a complex task.
As per claim 6, Raghu further discloses wherein:
the task comprises a description of an operation to be performed in the computing platform and task parameters extracted from the use case input (Paragraph 12), and
the task context information includes:
for each tool of the plurality of tools (Paragraph 12 “The conversation-based software development program 101 may transform the natural language task specification into a domain independent data flow graph 204. In the context of the present invention, for a data flow graph to be domain independent means that the graph can express a program specified by the developer only in terms of its inputs and outputs, and not in terms of its specific operating environment, hardware, API calls, etc. The domain independent data flow graph may include a number of substeps 206, which may be represented as nodes connected by edges. The edges may specify inputs to outputs of the various substeps 206 such that the domain independent data flow graph 204 specifies a mapping of inputs to outputs for the eventual result program 216.”):
a description of one or more operations that are performed by the tool in the computing platform, an indication of suitable inputs for the tool, and an indication of expected outputs for the tool (Paragraph 12); and
an indication that the second large language model should provide as an output an identification of a tool capable of performing the operation in the computing platform and an indication of one or more tool inputs for the identified tool in order to perform the operation (Paragraph 12).
As per claim 19, it is an apparatus claim having similar limitations as cited in claim 5 and is thus rejected under the same rationale.
As per claim 20, it is an apparatus claim having similar limitations as cited in claim 6 and is thus rejected under the same rationale.
Claims 7-10 are rejected under 35 U.S.C. 103 as being unpatentable over Miller in view of Raghu in further view of Wu (US 20200012521).
As per claim 7, Miller does not expressly disclose but Wu discloses further comprising:
building, by the planning agent, a directed dependency graph of the plurality of tasks based on one or more dependencies between tasks of the plurality of tasks (Paragraph 6 “processing a plurality of tasks in parallel. The method may include generating a directed acyclic graph based on dependencies among the plurality of tasks that are to be executed by the at least one processor, distributing the plurality of tasks to a plurality of work queues of the at least one processor based on the directed acyclic graph, and regulating, in respective work queues, one or more distributed tasks to be executed in parallel based on the dependencies among the one or more distributed tasks indicated by the directed acyclic graph.”), and
scheduling execution of the tasks based on the directed dependency graph (Paragraph 27).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Miller as modified to include the teachings of Wu because it allows for topologically sorted tasks based on the task dependencies represented in the directed acyclic graph.
As per claim 8, Wu further discloses wherein the planning context information includes a description of the one or more dependencies between the tasks of the plurality of tasks (Paragraph 6).
As per claim 9, Wu further discloses wherein a first task is dependent on a second task, and wherein the planning agent provides the first task to the respective task agent based on execution of the second task being completed (Paragraph 6).
As per claim 10, Wu further discloses further comprising: identifying tasks that can be performed in parallel and executing the identified tasks in parallel (Paragraph 6).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wolfman (US 20220092075) discloses optimizing a plurality of data integration tasks within a data integration collection by identifying, as a sub-set of the plurality of data integration tasks, a plurality of point-to-point data integration tasks defining a data integration transformation plan to include: generating one or more publication data integration tasks comprising publishing from each respective data source of the plurality of point-to-point data integration tasks to generate a single publication topic; and generating one or more subscription data integration tasks causing each respective target of the plurality of point-to-point data integration tasks to subscribe to the single publication topic; and generating a set of optimization instructions configured to cause the at least one computer to implement the data integration transformation plan; and executing the set of optimization instructions to generate the one or more publication data integration tasks and the one or more subscription data integration tasks.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY A MUDRICK whose telephone number is (571)270-3374. The examiner can normally be reached 9am-5pm Central Time.
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, Pierre Vital can be reached at (571)272-4215. 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.
/TIMOTHY A MUDRICK/Primary Examiner, Art Unit 2198 8/27/2026
Prosecution Insights