DETAILED ACTION
This action is responsive to the Application filed 9/24/2024.
Accordingly, claims 1-21 are submitted for prosecution on merits.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 8 is/are directed to an Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following 2-step analysis.
Step 1:
The claim is directed to method/process category.
Step 2A:
Prong One:
Claim 8 recites the steps of:
selecting a Foundation Model (FM)-based agent from a repository based on skills,
selecting a communication architecture, and
decomposing and executing a sub-task using the architecture and agent.
These steps, when stripped of technological jargon, are directed to an Abstract Idea. Specifically, the concept of evaluating skills, choosing a communication structure, and breaking down a large task into smaller components is a fundamental Method of Organizing Human Activity (such as project management or delegating tasks to qualified personnel) and a Mental Process (MPEP § 2106.04(a)(2)), the operations of "selecting" and "decomposing" represent basic conceptual processing steps that can be (and historically have been) performed by human minds or via pen and paper, the recitation of an "FM-based agent" and a "communication architecture" simply replaces a human worker and a corporate reporting structure with generic computing equivalents.
Prong Two:
Per MPEP § 2106.04(d)(2), an abstract idea is not integrated into a practical application if the claim elements merely append a generic judicial exception to a specific technological environment, or if the claim recites nothing more than "apply it" (the abstract idea) using generic computer components.
The claim features high-level, purely functional language ("selecting," "decomposing," "executing") without providing any technical details, underlying algorithms, or specific hardware modifications showing how the “FM-based agent” is structurally configured, or how the architecture structurally alters the network. Other technical details or concepts (like “architecture”, “problem domain”, “complexity of a subtask”, “context”) do not amount to more than their ordinary meaning in order to prove that a non-conventional mechanism is driven by those concepts; the components ("repository," "agent," "architecture") are used according to their ordinary, generic capacities to simply execute the abstract workflow, the claim does not improve the underlying functioning of the computer system itself or any specific technology; rather, it uses the computer as a tool to run the abstract task-delegation workflow. Therefore, the judicial exception cannot be integrated into a practical application
Step 2B:
Individually: The additional elements comprise a generic storage ("repository"), algorithmic entities ("FM-based agent"), and software frameworks ("communication architecture"). Per MPEP § 2106.05(a), adding generic computer components executing routine data-processing functions does not supply "significantly more."
As an Ordered Combination: The combination of these steps describes a standard sequential loop: sorting data based on attributes, selecting a path, splitting the data, and processing it. This sequence represents the conventional, routines, and well-understood operations of data management software and automated task dispatching.
Because the claim simply commands the practitioner to take an abstract management strategy and "apply it" using a generic foundation model infrastructure, it fails to recite an inventive concept under 35 U.S.C. § 101.
Claim 8 is deemed non-eligible under 35 USC § 101 statute.
Step 2B analysis for dependent claims.
Claim 9 recites automatically generating a new agent with code of a given skill, an architecture for communication between a existing agent and the new agent, where the execution is given to the new agent. Submitting a code to an agent amounts to extra-solution activity that makes use of the result from a abstracted steps of selecting, and mention of a architecture for enabling communication simply recites an intended use without meaningful description of the underlying computer transformation or HW arrangement that improves use of agent in a context where certain requirement or complexity are at stakes. MPEP 2106.05 (a) (c ) (g)
Claim 10 describes a group of agents in a generic form, and the type of communication associated with the selected architecture; these additional elements are rather descriptive and lack functional relationship /linkage with the Abstract Idea; thus fails to add significantly more to the Abstract Idea.
Claims 11-12 recite using local memory for a agent to track and exchange result/information; and a global memory to share data among group of agents. Use of memory to support storage of activity data was a known concept thus add no significant or inventive limitations to the Abstract Idea.
Claims 1 and 13 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 1 and 13 is/are directed to an Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following 2-step analysis.
A. Eligibility of claim 1
Per step I, claim 1 is directed to a method/process category.
Per step2A:
Prong One:
The steps elements recited include:
generating an initial plan indicative of tasks based on a received requirements document,
iteratively generating adjusted versions of the plan,
verifying that the current plan matches the initial requirements, and
formatting/compiling the plan into a structural format (graph) and providing it for execution.
These limitations describe an abstract framework that falls into the enumerated groupings of Certain Methods of Organizing Human Activity (specifically, managing a multi-stage task workflow) and Mental Processes (specifically, the human actions of reviewing, comparing, editing, and mapping structural checklists). These limitations represent presence of a Judicial Exception of a Mental Process type – MPEP 2106.04(a)(2) Independent of computer execution, the concept of a human project manager taking natural language client requirements, turning them into a task list, validating them with a supervisor, mapping out a workflow tree (graph format), and passing it to a worker represents conventional organizational behavior, the recitation of "first," "second," and "third" FM-based agents are merely viewed as functions to substitute individual generic software entities for standard human roles.
Prong Two:
The features recited as “generating”, “verifying”, “compiling” and “providing” amount to purely functional language, and as expressed in a high level of generality, they fail to improve the baseline functioning of a computer or an underlying technological field.
There is no description about “foundation model” (FM) as to a clear, specific technical modification to the internal mechanism of the foundation models themselves, the “agents” are deployed according to their ordinary, generic capabilities (taking text inputs and generating text outputs). Converting a task plan into a generic "executable graph format" is a well-understood routine data-formatting step that does not alter computing hardware or network topology, the claim does not resolve a technical computing constraint; it simply uses the computer as a vehicle to automate a conceptual business management workflow. Consequently, the abstract idea cannot be integrated into a practical application – MPEP 2106.04(d)(1)
Step 2B:
The elements evaluated individually and as an ordered combination fail to establish an inventive concept:
Individually: The components ("FM-based agents," "natural language requirements," "executable graphs", “compiling”) in terms of “additional elements” represent generic, well-understood tools, machine learning modules and standard data structures. Utilizing multiple AI instances to cross-verify output is a common application-level architecture.
Ordered Combination: The sequence of operations replicates a standard closed-loop validation pipeline (Draft → Iterate → Verify → Compile → Execute). Adding generic computer entities to process information through a standard logical loop does not elevate the combination to "significantly more".
Because the claim simply directs the practitioner to execute an abstract planning-and-review workflow using standard foundation model frameworks, it is ineligible under 35 U.S.C. § 101. MPEP 2106.05 (a)(f)(h)
The additional elements thus mentioned fail to add significantly more to the Abstract Idea of step 2A.
Claim 1 is deemed un-eligible under 35USC § 101 statute
B. Eligibility of claim 13
Per step I, this claim is directed to a system/apparatus category.
Per step 2A, prong one
Claim 13 recites the same limitations as claim 1, in terms of
generating an initial plan indicative of tasks based on a received requirements document,
iteratively generating adjusted versions of the plan,
verifying that the current plan matches the initial requirements, and
formatting/compiling the plan into a structural format (graph) and providing it for execution
As mentioned above in the analysis of claim 1, these limitations represent presence of a Judicial Exception of a Mental Process type – MPEP 2106.04(a)(2)
Per step 2a, prong two:
The features recited as “generating”, “verifying”, “compiling” and “providing” amount to purely functional language, and as expressed in a high level of generality, they fail to improve the baseline functioning of a computer or an underlying technological field.
There is no description about “foundation model” (FM) as to a clear, specific technical modification to the internal mechanism of the foundation models themselves, the “agents” are deployed according to their ordinary, generic capabilities (taking text inputs and generating text outputs). Converting a task plan into a generic "executable graph format" is a well-understood routine data-formatting step that does not alter computing hardware or network topology, the claim does not resolve a technical computing constraint; it simply uses the computer as a vehicle to automate a conceptual business management workflow. Consequently, the abstract idea cannot be integrated into a practical application – MPEP 2106.04(d)(1)
Step 2B:
As mentioned earlier in the analysis of claim 1 in regard to the additional elements, claim 13 simply directs the practitioner to execute an abstract planning-and-review workflow using standard foundation model frameworks, it is ineligible under 35 U.S.C. § 101. MPEP 2106.05 (a)(f)(h)
The additional elements thus mentioned fail to add significantly more to the Abstract Idea of claim 13 determined per step 2A.
Claim 13 is deemed un-eligible under 35USC § 101 statute
Step2B analysis of dependent claims.
Claims 2 and 14 recite accepting feedback of a given action from a plan and generating a current plan based on the feedback. These actions fall into the enumerated groupings of Certain types of Organizing Human Activity (specifically, managing a multi-stage task workflow) and Mental Processes (specifically, the human actions of reviewing, comparing, re-editing, and re-mapping existing structural data/checklists). These limitations represent presence of a Judicial Exception of a Mental Process type – MPEP 2106.04(a)(2)
Claims 3 and 15 recite acquiring human approval for a given plan; and this activity falls under the well-understood routine in accepting data by a process that perform mental analysis and derivation from a set of input; thus, fail to add significantly more to the Abstract Idea of the base claim.
Claims 4 and 16 recite which type a initial requirement can be; and this additional descriptive information cannot signify a transformation or a improvement to the computer field in which the Abstract Idea operates.
Claims 5 and 17 recite a plan being a textual description or graphical representation; and this additional descriptive information cannot signify a transformation or an improvement to the computer field in which the Abstract Idea operates
Claims 6-7 recite selecting a new agent and specifying a skill for the new agent obtained from a repository, and this constitutes an insignificant extra-solution activity that fails to add significantly more to the functioning of abstract idea of the base claim.
Claim 18 recites the combination of features in claim 8 and claim 9; hence is viewed as a subject matter that is directed to mental processes type of Judicial exception, as set forth above.
Claim 19 recites descriptive information on the group of agents as recited in claim 10; thus fails to add significantly more to the Abstract Idea
Claims 20-21 recite additional descriptive and conventional feature as recited in claims 11 and 12 (local memory and global memory), respectively; therefore fail to add significantly functional improvement to the Abstract Idea.
In all, claims 1-21 are deemed non-eligible under the 35 USC § 101 statute.
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-3, 5, 13-15, 17 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Medford, USPubN: 2025/0165890 (herein Medford), in view of Raimondo et al, USPubN: 2024/0176958 (herein Raimondo) and Xiong et al, USPubN: 2025/0378276 (herein Xiong)
As per claim 1, Medford discloses a computer-implemented method, comprising:
acquiring an initial requirement in natural language (initial requirement and strategic objectives, as specified by a user – para 0021);
generating, using a first FM-based agent (Planner Agent – para026; multi-agent setup, the output of one agent … seamless flow of information … and tasks across the system … Planner Agent might generate a detailed project plan – para 0021 – Note0: Large Language Models agents – see Abstract - reads on FM-based agent) and based on the initial requirement, a plan (para 0021; allows each agent to excel in its respective areas, such as planning, coding, testing or quality assurance – para 0020 – Note1: complementary agents such as MemGPT and Critic Agent – para 0026 – integral to context of the planning coordination or direction of a Planner agent reads on agent component integrated with or underlying a core first agent to form a plan) indicative of tasks (allows the multi-agent AI to maintain … nuanced understanding of complex software project and context-aware operations across … development tasks – para 0024) and skills (nuanced understanding of complex software project, this capability is advantageous for handling codebases … that traditional LLMs struggle … MemGPT agent ensures that all relevant data is … contextually appropriate, thereby enhancing … understanding and operational efficiency – para 0024; this capability allows the MemGPT agent to provide tailored context … ensuring that the information it delivers is both relevant and … applicable to the task at hand - para 0025 – Note2: capability to understand nuances in complexity of software project and context of operations, immediate applicability to tasks reads on skills for achieving an objective) or achieving an objective (see task at hand – para 0025);
iteratively generating, using the first FM-based agent (Planner agent – para 0055 – refer to Note1), adjusted versions of the plan (refine the project … for iteratively development processes – para 0064), during a given iteration:
verifying (see below), using a second FM-based agent (Critic agent being a sub-component agent – see para 0026; Critic Agent – para 0061-0063; para 0065; as a checkpoint … that every element of the project … aligning with the strategic goals and technical demands of the project - para 0066 – Note3: Critic agent instance among multi-agent orchestration aspect underlying a core Planner agent reads on using a second agent as part of the core first agent – see Note1), that a current version of the plan matches the initial requirement (evaluate … feasibility … assess the quality … and compliance … with established standards … ensure that every component … meets or exceeds the predefined criteria … receiving the project plan … then analyzes to identify any potential … flaws or deviations from the project specifications – para 0061);
compiling documentation versions of the plan in an executable graph format (graph construction links related code and documentation sections, providing better visualization and navigation of the software project – para 0042);
providing the compiled plan (Planner 204, Agent 204[Wingdings font/0xE0]codebase context; Critic agent 206 code quality [Wingdings font/0xE0] Engineer agent 208; flow of information between various specialized agents, output generated by the Planner Agent … transformed into executable code – para 0046) for execution by a third FM-based agent (Agent 210 – Fig. 2; Agent 210 – Fig. 3; para 0059)
A) Medford does not explicitly disclose
compiling a latest version of the plan in an executable graph format, thereby generating a compiled plan and providing the compiled plan for execution.
Xiong discloses development of LLM project (para 0109-0110) using AI platform on which a AI copilot system utilizes AI agents cooperating with an agent core and a planner tools (Fig. 8) via a UI on basis of documentation and Retrieval-Augmented Generation (RAG) for data summarization and representation, with connection to external data sources and added interfaces as added flexibility into effect of implementing tasks (para 0127), for developing knowledge graph (para 0115) on basis of the information sources, the graph having interconnected concepts and providing context to the planner; -- e.g. generating training data in form of question-answer scenarios and relevance information by which the user can interact via a UI to develop report and action plan(para 0117-0118) - the plan designed as a roadmap (para 0090) to guide the agents action in accordance with the course of action for a problem or task (para 0080-0081) - e.g. using prompt template to outline the actions to be taken(para 0089); hence representing knowledge graphs with interconnected concepts on basis of documentation data, user cases, RAG flow coupled with query/question scenarios raised by AI agent (para 137) as part of decision-making process of a planner platform entails compiling various aspect of a original plan into a graph format expressing compiled action plan with which to execute a complex scenario.
Raimondo also discloses task-oriented conversation framework and workflow plans using pretrained NL model to implement a chatbot workflow involving LLM learning and associated agents using prompts (Fig. 2) to represent context of scenario or dialogs (para 0023) forming various workflows under consideration by a planner component (planner 106 – Fig. 1), where representation of the plan steps can be used to guide the machine learning model in accordance with the utterance and progression of the conversation/dialog workflow (Fig. 3), where prompting information encoded for use by the machine learning includes parameter and actions associated with utterances and context of workflow items (Fig. 5), names for each action, where a directed graph can be used to represent the dialogue context, and option for action, indicative of multiple paths for achieving a goal, a workflow in form of a tree in close association with an action plan (para 0037). Hence, use of graph format for expressing compilation of workflow items and action plan with which to execute a complex conversional scenario using LLM-based communication agents is recognized.
Therefore, as use of feedback by a Critic Agent (para 0064) continuously refines a development process under a planner (Fig. 2), an iterative process via continuous cycles (para 0010, 0015) by which a project is to be built, altered or reconfigured as shown in Medford (para 0028) entails generating a compilation based on the latest version of a planned project or revised software is recognized.
Thus, based on role of agents in forming the final compilation of a plan, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the planner stage in light of the latest version of planned project in Medford, so that the latest representative version of this planned project would be converted into a graph type workflow or tree like expression, so to form a compiled plan; i.e. by converting a latest version of the plan in an executable graph format – as set forth in Xiong knowledge graph and Raimondo DAGs; because
a version of a plan construed from a framework after various stages of UI adjustments by the user, injection of specifications or continuous augmentation of knowledge when deemed sufficiently compliant with the user context, a task objective, or a design requirement should be the most proper set of configuration to be destined for compilation into another format for deploying a intended objective, and converting a latest version of a plan resulting from cycles of editing, improvement from a LLM planner framework in Medford into a graph representation would better express the action items, the parameter and conditions attached to the actions in exposing tree nodes, edges dependency that very much facilitate effect of navigating the workflow defined from relationships and invocation branching on the graph by a algorithmic translation during a plan compilation stage, which in turn would be able to convert all the parametric information and contextual data from the graph actions and constraint relationships thereon into a programmatic and context-compliant logic flow, as intended for deploying a task using the LLM agentic-support framework in Medford.
As per claims 2-3, Medford discloses method of claim 1, wherein the iteratively providing (para 0010, 0064) further comprises, during the given iteration:
(i) acquiring a human feedback (developers … can use a user interface … to view the commit, current branches – para 0083; means for users to review the feedback, enables them to make … decisions … user adds an additional layer of oversight… final outputs … meet technical standards … align with … goals and expectations – para 0065; user feedback, real-world user interactions and responses - claim 6, pg. 11; integration of user feedback - para 0034) for adjusting a previous version of the plan, the feedback being indicative of at least one of the following actions:
re-arranging at least one task in the previous version of the plan;
adding at least one task to the previous version of the plan;
removing at least one task from the previous version of the plan;
modifying at least one task in the previous version of the plan;
requesting to expand sub-tasks of at least one task in the previous version of the
plan; and
accepting at least a portion (approvals – para 0065; display the generated project plans for review and approval – claim 3, pg. 11) of the previous version of the plan; and
rejecting at least a portion (review and approval – claim 3, pg. 11) of the previous version of the plan; and
generating (refer to claim 1), using the first FM-based agent, the current version of the plan based on at least the human feedback (user feedback, real-world user interactions and responses - claim 6, pg. 11);
acquiring a human approval of the current version of the plan (approval before task delegation to the Engineer Agent - claim 3, pg. 11; developers … can use a user interface … to view the commit – para 0083; para 0065), the current version being the latest version of the plan for compilation.
As per claim 5, Medford discloses method of claim 1, wherein the plan comprises at least one of a textual description (para 0038) and a graphical representation (knowledge graph – para 0042).
As per claim 13, Medford discloses a computer system comprising one or more processors, and a memory storing instructions, when the instructions are executed by the one or more processors, the computer system is configured to:
acquire an initial requirement in natural language;
generate, using a first FM-based agent and based on the initial requirement, a plan indicative of tasks and skills for achieving an objective;
iteratively generate, using the first FM-based agent, adjusted versions of the plan, during a given iteration:
verify, using a second FM-based agent, that a current version of the plan matches the initial requirement;
compile a latest version of the plan in an executable graph format, thereby generating a compiled plan; and provide the compiled plan for execution by a third FM-based agent.
( All of which having been addressed in claim 1)
As per claims 14-15, refer to rejection of claims 2-3 from above.
As per claim 17, refer to rejection of claim 5.
Claims 4, 16 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Medford, USPubN: 2025/0165890 (herein Medford), in view of Raimondo et al, USPubN: 2024/0176958 (herein Raimondo) and Xiong et al, USPubN: 2025/0378276 (herein Xiong), further in view of Lin Jia-Hui, TW M648831 (translation) 12-01-2023, 8 pgs (herein Lin)
As per claim 4, Medford does not explicitly disclose method of claim 1, wherein the initial requirement comprises an indication of Standard Operating Procedures (SOPs) and a series of steps for achieving the objective.
However, the LLM multi-agent framework in Medford includes agent stages initially operating in a directional flow but inter-relate cyclically among themselves with an end-of-stage review/feedback check by a authority before the result from that one stage can be passed to a next stage, the agent-based stages including a core agent (Planner stage) that receives initial user requirements , a agentic storage processing stage (memGPT agent), a critic stage (critic agent), an engineer agent stage responsible for code generation, and an executor stage for execution or testing (para 0013), all under an inter-related cyclic SW building paradigm (memGPT 104[Wingdings font/0xE0]agent 204 [Wingdings font/0xDF] Critic agent 206; memGPt[Wingdings font/0xE0]Engineer Agent [Wingdings font/0xDF] critic agent – Fig. 2) in which, the memGPT interacts with the Engineer agent and the storage (para 0024-0025) to manage user contextual accuracy to enhance efficiency of SW project, and render decision on commits of developed SW to store (para 0008, 0010; Fig. 3), where quality of the derived plan from the user input is ensured via feedback from the Critic Agent (para 0013, 0018, 0022, 0026) to the MemGPT, the planner stage and the engineer stage in terms of a quality control for ensuring that the proposed/developed plan meets the specifications, context and requirement as intended (para 0018, 0022) the focus of which in evaluating adherence to SW modules predefined standards (para 0022), where within iterative loops for development of code engaging the code to repository, where the MemGpt and Engineer agent (para 0010) in conjunction with data interchange with the other agents would determine fate of the code - to commit, to store or resubmit to for further improvement - added thereto with a human-in-the-loop effect by which the engineer stage can receive user feedback (review approval) to ensure that complex aspect of the project would align with organization goals and user expectations (para 0065; claim 3, pg. 11), whereby the engineer agent would implement modifications and/or provision a clear audit trail to the development of versions or rollback thereof (para 0028), the latter provided with accurate documentation of improvement or changes recording within lifecycle of the project; e.g. via use of VCS under GitHub (para 0029) methodology. Hence the cyclically related steps spanning the agent-based inter-cooperation from generating a proposal to deployment of code enhanced with feedback, quality control, adherence to standards, reviewing, modification, testing, auditing, and decision on commits and documentation of changes clearly indicate a solid standard procedures for processing SW and committing version storage or would have rendered this “SOPs” methodology clearly evident or obvious.
Lin discloses use of standard operating procedures (SOPs) as norm for a project construction and management system using a planning module configured to provide multiple constructions based on standard operating procedures via different components of the project in conjunction with software programs disposed in relevant storage(pg. 3)
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the LLM agent-driven stages of code planning, quality and conformance checking, context management and repository commit, reviewing/approval added with human-in-the-loop interaction, testing and code modification, and audit tracking and documentation on code changes – as set forth above - with reference or adherence to predefined standards, such as a SOPs – as per Lin - specified as part of the initial requirements into the start of a planner stage; because
conformance to or adherence to the SOP being foundation for constructing a project, proposing a plan, code testing and review, end-to-end quality check and documentation, consolidating code development and managing code towards versioning or storage commit would augment the credibility of the code asset being constructed when it is made available as product for distribution, adding thereby a confidence factor to the prospected users in light of the knowledge that proper/established standards had been applied with the development and quality control of the product, a factor which would most likely enhance marketability or augment desirability of the SW product.
As per claim 16, Medford discloses computer system of claim 13, wherein the initial requirement comprises an indication of Standard Operating Procedures (SOPs) and a series of steps for achieving the objective.
(refer to rationale of claim 4 from above)
Claims 6-10, 18-19 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Medford, USPubN: 2025/0165890 (herein Medford), in view of Raimondo et al, USPubN: 2024/0176958 (herein Raimondo) and Xiong et al, USPubN: 2025/0378276 (herein Xiong), further in view of Desgarennes et al, USPubN: 2023/0381664 (herein Desgarennes)
As per claims 6-7, Medford does not explicitly disclose method of claim 1, wherein the method further comprises
generating a new agent in an agent repository by specifying skills for the new agent;
selecting an existing agent in an agent repository.
Desgarennes discloses importing a personalized agent (para 0004) employable for user’s intent to perform a task, using a foundation model environment(para 0020) to support computer vision, speech recognition, gameplay learning (para 0035) where a agent library (para 0031) supports instantiation (para 0034) via prompt-based personalization (Fig. 1B) of agents whose personalization (Fig. 5) provide the user with analytics service (para 0005), interpretation of commands from gaming interactions (para 0025-0026), of video, audio, haptics of game on various exposed APIs(para 0024-0025) so to complement the user play style/strategies (para 0029), the instantiated agents personalized into user’s context in which model trained data can be adapted to a wide range of tasks (para 0031) such as game interactions; the agent library (containing specific builds, different styles of agents – para 0039) enabling different style of agents to be selected based on personalization request (para 0054) and imported (para 0035) for foundation model in-game service of a user context to carry out the personalized tasks (para 0027) under the user communication, playstyles and preference strategies
Hence, personalization of library-stored agent by the user to carry particular gaming-related actions or interpretation entails generating a new instance of a agent from a repository, the selection thereof based on functional capability of the agent to handle a special task as intended by the user.
Thus, based on various specialized agents (para 0047) in Medford multi-agent framework where a new specialized version of agent can be introduced (new specialized agent - para 0081), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Medford multi-agent LLM framework and agent-based development of computational SW workflow so that this framework operates with support of an agent repository containing various styles and builds of agent – as set forth in Desgarennes library – enabling an existing agent to be selectively fetched from the repository, for instantiation under a user customization context – as per Desgarennes – to render a task or functional design, the agent repository configured to contain of existing agents and newly generated agent organized in accordance with their skill specificity; e.g. administering a new agent by the repository in response to a determined specific skill or capability type thereof, and storing it with all existing agents for the prospect of their import according to their specific capability into a user context – as set forth in Desgarennes; because
provisioning of agent software administered with their specific skill and capability in a repository as set forth above would enable a external development framework (LLM multi-agent development and orchestration workflow) to specify via a request functional characteristic, or requirements descriptive of a function to expect from the agent software, so that identification of a agent responding to the request would trigger an instance thereof for import into the external framework, thereby minimizing the framework resource for having to reconfigure the agent functional capability from scratch and accelerating customization of the agent for a immediate real-world application or support for user operational preferences , as shown in Desgarennes.
As per claim 8, Medford discloses a computer-implemented method, comprising:
selecting, using a first FM-based agent (refer to claim 1), at least one existing agent available on an agent repository (refer to rationale of claim 6-7 using Desgarennes) to execute a given sub-task (task delegation among various specialized agents – para 0047; task delegation – claim 1, 3 pg. 11) in a plan (refer to claim 1; para 0053) based on at least one of skills of the existing agents (capability can be integrated … enhancing role of the Engineer agent by introducing a new specialized agent – para 0081), and complexity of the given sub-task (para 0014-0015);
selecting an architecture (e.g. architecture which can be installed – para 0012; ensure the plan aligns with the overall project architecture and existing functionalities – para 0032) for communication (Fig. 2-3; para 0091) between the at least one existing agent (see information passing per para 0052-0070), the selecting being based on at least one of: a problem domain, the complexity of the sub-task (para 0014), and a context (contextual information, necessary context, relevant context, enriched context – para 0050-0051; context window – para 0057) and
decomposing (delegation – para 0047; task delegation – claim 1, claim 3 pg. 11; breaks down into manageable components – para 0053; delegation and execution – para 0018) and executing (task delegation and execution – see Abstract) the given sub-task (para 0067, 0069-0070) using the selected architecture (see above) and the at least one existing agent (refer to Fig. 2-3).
As per claim 9, Medford discloses method of claim 8, wherein the method comprises further comprises dynamically and automatically generating a new agent (capability can be integrated … enhancing role of the Engineer agent by introducing a new specialized agent – para 0081) with generated code as a given skill (see Engineer specialty from above – para 0081); hence using a new agent having an Engineer skill is recognized.
Medford does not explicitly disclose the selected architecture being for communication between the at least one existing agent and the new agent, and wherein the decomposing and the executing the given sub-task further comprises using the new agent – referred herein as (*)
The communication architecture in Medford entails information passing and feedback returned from data processed at various agents whose involvement form a multi-agent cooperative and repetitive cycle (Fig. 2, 3, 4; see para 0052-0070) originating from a Planner layer receiving the initial requirement and breaking it down into components or tasks, from which plan-related data is transferred first, to the MemGPT agent, on which structured data from the planner can be verified as conforming for ingestion to a repository, then processed by a Critic agent for checking if the construction is conformant to norms and code quality, as well as an Engineer agent whereby the generated software is checked for conformance in connection with feedback-based decision making so as to either commit the code for a version control or else for further testing, under service of an Executor agent.
Hence, selection of a communication architecture that is technically compliant and properly equipped (para 0003-0004, 0009) to implement continuous, extensive and repetitive workflow tasks and information passing between the stages of a planner paradigm leading to generating, testing or retesting, consolidating a verified, conformant code for commit into a backend repository is either disclosed or would have been obvious.
Therefore, based on flexibility to instantiate new agent in response to demand for a new type of operation or task in the multi-agent framework by Medford, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Medford’s software development so that necessitated software of a given skill can be implemented with one or more additional agent and that inter-communicated data between said multiple multi-agent operational cycles is based on proper selection of a robust communication fabric equipped with architectural capacity and provisioning in order to sustain continuous, extensive and repetitive workflow tasks and information passing – e.g. between the stages of agentic operations (e.g. Planner agent, MemGPT agent, Critic agent, Engineer agent, Executor agent etc.) in which the selected communication architecture would be capable of sustaining operations and communication between the at least one existing agent and a new agent – as set forth above in (*) - so that the decomposing and the executing a given sub-task also comprises skillset of the new agent; because
applying continuous and possibly cyclic stages of the multi-agent software development into fabric of a NW architecture in terms of decomposing core specifications into actionable components and tasks as part of planning, verifying whether software representative thereof is compliant against code standards and context of the existing repository SW asset, rendering immediate decision based on feedback to further test the developed software or commit it as finished product for storage intrinsically requires provision of intercommunication NW protocol and peripherals, of APIs and traffic supporting HW and SW whereby transmitted/received data is maintained as continuously trustworthy for their respective application scenarios, compliant to settings of security, integrity and availability throughout the course of their being transmitted, received, processed and resent back to the cycle of communication required to fulfill the multi-agent pipeline;
such provisioning including coverage of any extension made to the multi-agent development process - adding of new agent into the existing agentic pool - in that a responsive decision making be issued so to not only enlist adequate HW/SW entities capable of accommodating augmented demand the agentic traffic by the same architecture; but also to not overstretch allocation of resources beyond the limit of support capability by this communication architecture.
As per claim 10, Medford discloses method of claim 9, wherein the at least one existing agent and the new agent (refer to adding a new Engineer agent – para 0081) form a group of agents (see multi-agent AI system, built around a group of LLMs, each LLM as an automated agent – para 0019) , and wherein the selecting the architecture (refer to rationale of claim 9) comprises selecting for communication between the group of agents at least one of: a peer-to-peer conversion pattern architecture, a hierarchical conversion pattern architecture (see para 0052-0070; Fig. 2-3, 4).
As per claim 18, Medford does not explicitly disclose computer system of claim 13, wherein the computer system is further configured to:
(i) select, using a fourth FM-based agent, at least one existing agent available on an agent
repository to execute a given sub-task in a plan based on at least one of skills of the existing
agents, and complexity of the given sub-task;
(ii) select an architecture for communication between the at least one existing agent, and the
new agent, the selecting being based on at least one of: a problem domain, the complexity
of the sub-task, and a context; and
(iii) dynamically and automatically generate a new agent with generated code as a given skill; decompose and execute the given sub-task using the selected architecture, the at least one
existing agent, and the new agent.
As per (i), instantiating a new agent specialized for responding to skill of a Engineer agent is shown in Medford as per necessity (para 0081) and capability to instantiate a agent from a pool or repository according to a application need to execute a subtask – e.g. from a component breaking down by a planner agent (para 0053) has been rendered obvious with rationale of claims 6-7 using the teachings by Desgarennes, where each agent instance can be customized for a given functional capacity administered with the repository
Where introducing a new agent as fourth agent from a repository as instance customized to execute a given sub-task in a plan would be deemed obvious using the flexible support of the repository for customization purpose as set forth with rationale 6-7 from above (using Desgarennes).
As per (ii) selecting a communication architecture comprising existing agent and a new agent based on a problem, a task complexity or a context has been addressed with the rejection of claim 8
As per (iii) the feature of : dynamically and automatically generate a new agent with generated code as a given skill; decompose and execute the given sub-task using the selected architecture, the at least one existing agent, and the new agent, has been addressed with rejection of claim 9.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the multi-agent SW development framework in Medford so that
Features (i) (ii) and (iii) would be implemented for obvious reasons proffered with rationale of claims 6-7, with rejection grounds set forth in claims 8-9 from above.
As per claim 19, Medford discloses computer system of claim 18, wherein the at least one existing agent and the new agent form a group of agents, and wherein to select the architecture comprises the computer system configured to select for communication between the group of agents at least one of: a peer-to-peer conversion pattern architecture, a hierarchical conversion pattern architecture.
( All of which having been addressed in claim 10)
Claims 11-12, 20-21 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Medford, USPubN: 2025/0165890 (herein Medford), in view of Raimondo et al, USPubN: 2024/0176958 (herein Raimondo) and Xiong et al, USPubN: 2025/0378276 (herein Xiong), further in view of Desgarennes et al, USPubN: 2023/0381664 (herein Desgarennes), Lu et al, CN 116360993 (translation) 06-30-2023, 20 pgs (herein Lu) and LI et al, CN 111600936B,(translation) 04-11-2023,14 pgs (herein LI)
As per claims 11-12, Medford does not explicitly disclose method of claim 9, wherein the decomposing and executing the given sub-task further comprises:
(i) using a local memory by the at least one existing agent and the new agent to at least one of: track intermediate results, and exchange information among the at least one existing agent and the new agent.
(ii) using a global memory to share data across: a first group of agents including the at least one existing agent and the new agent, and a second group of agents.
As for (i)
Lu discloses scheduler and task processing per a upstream downstream distribution of tasks orchestrated from a job manager (pg. 2) where data processed from task node stages of the distribution, are stored temporarily and passed downstream using a intermediate data agent when the processing has completed upstream, (pg. 7), according to which, result data temporarily stored from a upstream operation is being mapped to a local memory of the downstream node by the intermediate data agent acting as manager to improve data reading efficiency, where the by the intermediate stored result can be deleted from this local memory by the intermediate data agent for space recovery. Hence, use of local memory associated with agent operation to improve efficiency of the data reading and memory space usage is recognized.
As for (ii)
LI discloses a data exchange pipeline started at a core agent (data exchange agent, DEA) in a embedded system that invokes communication and task operation from a independent service agent via use of message queuer and a global memory (pg. 3; communication mechanism … shared memory – pg. 6) for the interactive data to be made available between the data exchange agent and the service agent, the service agent establishing exchange channel (pg.4) with the DEA and specifically used for issuing subscription algorithm to manage theme data, classifying and storing of the data (pg. 7); hence provision of a common memory between a core DEA agent and a invoked service agent via communication mechanism that include a shared memory data for use by both the two agents is recognized.
Thus, based on possibility that a new agent of a given capability can be instantiated (Engineer agent, new specialized agent - para 0081) for take on a specific task in Medford, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement interchange of information between respective agent operational context in the multi-agent LLM framework so that distributing plan tasks and executing the given sub-task based on the planner agent comprises:
(i) using a local memory by the at least one existing agent and the new agent to at least one of: track intermediate results, and exchange information among the at least one existing agent and the new agent – as set forth in Lu;
(ii) using a global memory to share data – as in LI - across: a first group of agents including the at least one existing agent and the new agent – one that implements a Engineer agent -, and a second group of agents; because
Local memory can be used to temporarily hold data awaiting completion from upper stage or task of a pipeline, and can support transfer of intermediate results to a lower part of the pipeline without substantial cost in storage resources by the distribution of task such as the multi-agent stage interaction in Medford framework, since locally stored data using this temporary storage mechanism can be readily deleted as soon as possible to recuperate the memory space; and use of memory at a more global level between distributed operations by pipeline of agents or hierarchy of nodes in form of shared memory established within a channel of communication connecting two interacting agents or hierarchized nodes would enhance prompt and efficient readability of data needed by each agent or node in regard to an expected fulfillment of task or operations for which the channel of communication has been particularly established for the nodes or agents.
As per claims 20-21, Medford does not explicitly disclose computer system of claim 18, wherein to decompose and execute the given sub-task further comprises the computer system configured to:
(i) use a local scratchpad memory by the at least one existing agent and the new agent to at least one of: track intermediate results, and exchange information among the at least one existing agent and the new agent.
(ii) use a global scratchpad memory to share data across: a first group of agents including the at least one existing agent and the new agent, and a second group of agents.
But the above use of local memory and global memory in support for realizing execution from task decomposition by a planner stage to that agentic operational context can pass intermediate result between stages of a workflow or read shared data particularly created for relevant agents or node has been rendered obvious per rationale of claims 11-12 from above.
Therefore, use of local scratchpad memory (i) and global scratchpad memory (ii) would have been obvious for the same reasons set forth in the rationale of claims 11 and 12 respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
July 23, 2026
Prosecution Insights