DETAILED ACTION
This action is responsive to Remarks and Claim Amendments filed on July 08, 2026.
Claims 1-2, 5, 8, 10-12, 15, 18 and 20 have been amended. Claims 6-7 and 16-17 have been canceled.
Claims 1-5, 8-15 and 18-20 are pending and presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns, paragraphs, figures 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 their 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.
Response to Amendments and Arguments
Claim Objections and 35 U.S.C. 112(b) Rejections
The claim objections regarding subject-verb agreement ("is" vs. "are") and hyphenation inconsistency ("machine-readable" vs. "machine readable") set forth in the prior Office Action are withdrawn in view of applicant's amendments to claims 1, 8, 11, and 18.
The 35 U.S.C. 112(b) rejection of claims 1 and 11 based on ambiguous antecedent basis for the term "goal" is withdrawn in view of applicant's amendments correcting the antecedent basis.
The 35 U.S.C. 112(b) rejection of claims 2, 10, 12, and 20 for indefinite recitation of "relevance" / "relevancy" without an objective standard is withdrawn as to claims 10 and 20 in view of applicant's amendment deleting the comparative relevancy language from those claims. However, the rejection is maintained, on modified grounds, as to claims 2 and 12: applicant's amendment deleted the comparative language ("the second relevance is higher than the first relevance") but left the claims reciting two "relevance" values with no operative relationship between them and no objective standard for what "relevance" measures, as set forth in the 35 U.S.C. 112(b) rejection below.
The 35 U.S.C. 112(b) rejection is otherwise maintained as to claim 13 (grammatical defect not corrected by amendment) and is newly applied to claim 11 (antecedent basis), as set forth below.
35 U.S.C. 101 Rejection
Applicant's arguments against the 35 U.S.C. 101 rejection have been fully considered but are not persuasive. The rejection is maintained under a modified analysis that accounts for the newly incorporated claim limitations, as set forth in the rejection below.
Applicant argues that the amended claim 1 recites a "concrete executable logic validation architecture" with two structurally distinct testcase generators, automated root-cause identification, and targeted refinement, which applicant contends is not a mental process and is analogous to the specific rules found patent-eligible in McRO.
This argument is not persuasive for at least the following reasons. First, applicant's reliance on McRO, Inc. v. Bandai Namco Games America Inc., 837 F.3d 1299 (Fed. Cir. 2016) is misplaced. In McRO, the claims recited specific rules — for example, first-set and second-set morph weight rules keyed to phoneme timing — that were not the same operations performed by human animators, and that produced technical improvements in computer-generated animation not achievable by prior manual techniques. Here, applicant's "rules" are: (i) black-box test-case generation, (ii) white-box test-case generation, (iii) root-cause analysis on failure, and (iv) targeted refinement based on identified causes. Each of these is a well-known, conventional software engineering practice that humans have performed for decades. Software testers, developers, and quality-assurance engineers routinely draft input-output test cases from specifications (black-box), draft test cases based on inspection of source code (white-box), diagnose why code fails a test, and revise the code to address the identified cause. The claim thus organizes conventional human activities and mental processes, not specific technical rules that transcend human performance.
Second, applicant's argument that the claim is "fundamentally incompatible with mental performance" because it requires "processor-executed validation" and "machine access to the executable logic" conflates the abstract idea itself with the generic computer that implements it. The claim recites a "processor configured to" perform the recited steps — a generic computer component per MPEP § 2106.05(f). Requiring that the executable logic be executed by a processor merely means the abstract idea is implemented on a generic computer, which under Alice Corp. v. CLS Bank Int'l, 573 U.S. 208 (2014) does not confer eligibility. Similarly, an assertion that the second testcase generator "accesses" the executable logic describes the abstract concept of white-box testing (inspecting code to design tests), which is a mental process performed by humans, not a specific technical improvement.
Third, applicant's specification confirms that the recited operations are conventional. Paragraph [0041] of the as-filed specification defines the "first testcase generator" as "a 'Black Box Test Case Generator' that is a tool or component within a testing framework that is designed to automatically create test cases for black-box testing," wherein "[b]lack-box testing is an approach where the tester examines functionality of the system without detailed knowledge of its internal code or implementation." Paragraph [0042] similarly defines the "second testcase generator" as "a 'White Box Test Case Generator'" for "white-box testing" — "an approach where the tester has detailed knowledge of the internal code, logic, and structure of the software being tested." These are applicant's own admissions that black-box and white-box testing are well-known testing paradigms. See MPEP § 2106.05(d).
Fourth, applicant's argument that the amended claim requires "execution-dependent testcase generation and execution-state-dependent root cause identification" that "cannot practically be performed in the human mind" mischaracterizes the mental-process grouping. Under the 2019 PEG, a mental process encompasses concepts that could be performed in the mind or with the aid of pen and paper, but this does not require that every implementation be practically performable by hand. That the claimed process would be tedious or impractical for a human does not remove it from the mental-process grouping when the underlying concept is one humans have long performed. See MPEP § 2106.04(a)(2)(III).
Fifth, even assuming arguendo that the two-generator architecture and root-cause-driven refinement are integrated into a practical application, applicant's Step 2B argument that these elements amount to "significantly more" fails because — as detailed above and in the 35 U.S.C. 101 rejection below — each of the recited generators, the failure-detection mechanism, the root-cause identification, and the targeted-refinement mechanism is well-understood, routine, and conventional in the software testing arts, as confirmed by applicant's own specification and by the prior-art references applied in the 35 U.S.C. 103 rejection below (Li sections 7.2.1, 7.2.3 disclosing conventional unit-test generation and GPT-4 inspector for compilation/runtime error correction; Reflexion sections 3 and 4.3 disclosing conventional root-cause self-reflection and iterative refinement).
The 35 U.S.C. 101 rejection is accordingly maintained under the modified analysis set forth below, which accounts for the amended claim language.
35 U.S.C. 102(a)(2) Rejection over Li
The rejection of claims 1–20 under 35 U.S.C. § 102(a)(2) as anticipated by Li is withdrawn. In view of applicant's incorporation of former dependent claim subject matter (from canceled claims 6 and 7) into independent claims 1 and 11, together with new limitations directed to "root causes leading to the failure" being identified and a "subsequent version of the first executable logic" being refined to address those root causes, the anticipation rejection is replaced by a rejection under 35 U.S.C. 103, as set forth below.
Applicant argues that Li does not disclose (i) two structurally and functionally distinct testcase generators operating with different access relationships to the executable logic, and (ii) root-cause identification and targeted refinement. Applicant's arguments regarding the two-generator architecture have been considered and remain not persuasive under BRI, as Li discloses both a black-box test-case generator (Li, Section 7.2.3 "LLM-Based V&V," pages 22–23, disclosing generation of programming questions before any solution exists) and a white-box test-case generator (Li, Section 7.2.3 disclosing the GPT-4 inspector that examines generated code for compilation and runtime errors, and Section 7.2.1 "Unit-Tests-Based V&V," page 22, disclosing unit tests that target internal tree traversal, node execution order, and branch conditions). Applicant's characterization of Li's testcase disclosure as being limited to "dataset construction for model training" is inaccurate — Li Section 7.2.3 separately discloses both the Code LLaMA self-instruct process (which includes generating unit tests) and the GPT-4 inspector approach (which validates generated code for compilation and runtime errors and iterates until the code passes inspection).
As to root-cause identification and targeted refinement, applicant's argument that Li discloses only "observable failure states" without diagnostic root-cause identification is addressed in the 35 U.S.C. 103 rejection below, in which the Reflexion reference is applied for these newly-added limitations.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2, 11-15 and 18-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites "a first iteration of the validation operation has a first relevance to the first sub-skill and a second iteration of the validation operation has a second relevance to the first sub-skill." Claim 12 recites the same limitation in method form.
The term "relevance" is a term of degree for which the claim provides no objective standard. The claim does not define what "relevance" is measured against, how "relevance" is quantified, or what relationship (if any) exists between the "first relevance" and the "second relevance." The specification does not remedy this deficiency; paragraph [0044] merely restates the claim language without providing an objective standard for determining the "relevance" of an iteration "to the first sub-skill." As a result, a person of ordinary skill in the art would not be able to determine the metes and bounds of the claim — specifically, what limitation, if any, is imposed by reciting that a first iteration and a second iteration each have an unquantified "relevance" value with no recited relationship between them. See MPEP § 2173.05(b).
For purposes of applying prior art, the limitation is treated as being met by any two iterations of the validation operation, each having some relationship to the first sub-skill, as set forth in the 35 U.S.C. 103 rejection of claims 2 and 12 below.
Claim 11 recites, in the iteratively-refining clause, "such that in each iteration of the refinement of the generated first executable logic." There is insufficient antecedent basis for "the refinement" in the claim, as the claim previously recites the act of "iteratively refining" the first executable logic but does not previously introduce "the refinement" as a noun. It is noted that counterpart independent claim 1 recites "a refinement" (with the indefinite article) at the corresponding location, whereas claim 11 recites "the refinement," creating the antecedent-basis defect. Applicant may resolve this by amending claim 11 to recite "a refinement," consistent with claim 1.
Claim 13 recites "wherein the method further comprising receiving, by the processor, the input from another sub-skill connected to the first sub-skill in a logical flow." The phrase "wherein the method further comprising" is grammatically defective and renders the claim scope unclear, as it is indeterminate whether the recited "receiving" step is an additional required step of the method or a modification of a previously-recited step. Applicant may resolve this by amending the phrase to recite "wherein the method further comprises" or by deleting "wherein the method" such that the claim reads "further comprising receiving, by the processor, …." See MPEP § 2173.05(p).
Dependent claims 14-15 and 18-20 do not overcome the deficiency of the base claim and, therefore, are rejected for the same reasons as the base claim.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1–5, 8–15 and 18–20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1 — Statutory Category Claims 1–5 and 8–10 recite a system and are directed to a machine. Claims 11–15 and 18–20 recite a method and are directed to a process. Both are statutory categories under 35 U.S.C. § 101.
Step 2A, Prong One — Recitation of a Judicial Exception Claim 1, as amended, recites the following limitations that fall within the enumerated groupings of abstract ideas: (i) "receive an input comprising goal information … and requirement information" — receiving information (mental process); (ii) "generate a machine readable meta-plan … indicative of a set of sequential tasks that define a sequence of tasks and interdependencies" — decomposing a goal into ordered sub-tasks (mental process; a concept performed in the human mind by planners, project managers, and software architects); (iii) "generate a first executable logic based on the generated machine readable meta-plan" — producing an output responsive to a plan (mental process; humans routinely write instructions, prompts, or code from a plan, and per Spec [0052] "the first executable logic may include a prompt, code, tool or combination thereof"); (iv) "iteratively refine the generated first executable logic … in each iteration … one or more errors or inconsistencies in the first executable logic are removed" — iterative revision of an output based on comparison to a target (mental process); (v) "generate a set of testcases based on the first sub-skill … each of the set of testcases comprises an input-output pair" — drafting test scenarios from a specification (mental process; software testers routinely draft input-output test cases from a specification); (vi) "generate, using a first testcase generator, one or more primary testcases … without accessing the generated first executable logic" — black-box test-case design based only on external specifications, expressly identified in applicant's Spec [0041] as conventional black-box testing performed by testers "without detailed knowledge of its internal code or implementation" (mental process; methods of organizing human activity); (vii) "generate, using a second testcase generator, one or more secondary testcases … while accessing the generated first executable logic" — white-box test-case design based on inspection of code, expressly identified in Spec [0042] as conventional white-box testing (mental process; methods of organizing human activity); (viii) "when the first executable logic fails on either … one or more root causes leading to the failure are identified" — diagnostic reasoning about why an output failed (mental process; humans routinely perform debugging and root-cause analysis); and (ix) "a subsequent version of the first executable logic is refined to address the identified one or more root causes" — revising an output to fix identified causes (mental process; humans routinely revise plans and outputs based on identified failure causes). Considered individually and collectively, these limitations recite concepts that fall within the mental-processes grouping and the methods-of-organizing-human-activity grouping of the 2019 PEG. See MPEP § 2106.04(a)(2)(III) (mental processes) and § 2106.04(a)(2)(II) (methods of organizing human activity, including following rules or instructions). Claim 11 recites the same abstract idea as claim 1 in method form. The dependent claims (2–5, 8–10, 12–15, 18–20) further limit the abstract idea, as discussed below.
Step 2A, Prong Two — Integration into a Practical Application The claims do not integrate the abstract idea into a practical application. The additional elements beyond the abstract idea in claim 1 are (a) "a processor configured to" perform the recited steps, (b) the recitation that the meta-plan is "machine readable," (c) the recitation of the "first testcase generator" and "second testcase generator" as components, and (d) the recitation that when the first executable logic "is executed, an output dataset is generated." Each additional element is analyzed below.
(a) The "processor configured to" recitation is mere instruction to apply the abstract idea on a generic computer. See MPEP § 2106.05(f). A generic processor performing the abstract steps does not integrate the exception into a practical application.
(b) The recitation that the meta-plan is "machine readable" is mere instruction to store or format data in a computing environment. See MPEP § 2106.05(f).
(c) The "first testcase generator" and "second testcase generator" are recited at a high level of generality without any specific structural or algorithmic detail. Per applicant's Spec [0041]–[0042], these generators are generic tools within a testing framework that perform conventional black-box and white-box testing, respectively. They are accordingly mere instruction to apply the exception using generic tools. See MPEP § 2106.05(f). To the extent applicant argues that the two-generator arrangement itself constitutes a technical improvement, this argument is not persuasive: the arrangement is a conventional software-testing paradigm (black-box + white-box coverage) applied on a generic computer, which is not a specific technical improvement to the functioning of a computer or to any other technology.
(d) The recitation that executing the first executable logic generates "an output dataset" is insignificant extra-solution activity (data output) that generically follows execution of any code. See MPEP § 2106.05(g). Applicant's argument (Response, pages 5–7) that the amended claim recites a "concrete executable logic validation architecture" analogous to McRO's specific animation rules is not persuasive. The claim does not recite specific technical rules that produce a technical improvement not achievable by prior conventional practice. Rather, the claim recites at a high level of generality that testcases are generated (without specifying how), that root causes are identified (without specifying how), and that logic is refined to address root causes (without specifying how). These are results-oriented recitations of conventional software-testing concepts. See MPEP § 2106.05(a). Considered as an ordered combination, the additional elements do not integrate the abstract idea into a practical application. The combination is: use a generic processor to perform black-box test generation, white-box test generation, execution, comparison, root-cause identification, and refinement — all conventional software-testing concepts implemented on a generic computer. The dependent claims do not remedy this deficiency: Claims 2 and 12 (iteration relevance) recite the abstract idea itself and are mental processes. Claims 3 and 13 (input from another sub-skill) recite the abstract idea itself (organizing sub-tasks within a workflow) and, to the extent they recite receiving data from another component, that is insignificant extra-solution activity per MPEP § 2106.05(g). Claims 4 and 14 (revise + re-execute) recite the abstract idea itself (mental process of revising an output and re-checking it) and, to the extent they recite re-executing the validation operation, that is a well-understood, routine, and conventional computer operation per MPEP § 2106.05(d). Claims 5 and 15 (input-output pairs) recite the abstract idea itself (mental process of drafting test cases as input-output pairs). Claims 8 and 18 (natural-language feedback via chat interface + regenerate meta-plan) recite receipt of user input via a chat interface, which is (i) mere instruction to apply the exception via a generic user-interface element (chat interfaces are well-understood, routine, and conventional per MPEP § 2106.05(d), (f)), (ii) insignificant extra-solution activity (data receipt) per MPEP § 2106.05(g), and (iii) the abstract idea itself as to the plan regeneration (mental process of revising a plan based on feedback). Claims 9 and 19 (retrieve data from communication channel) recite data retrieval, which is insignificant extra-solution activity per MPEP § 2106.05(g); see also Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350 (Fed. Cir. 2016). The "communication channel" is a generic data connection, well-understood, routine, and conventional per MPEP § 2106.05(d). Claims 10 and 20 (utilize retrieved information to iteratively refine the meta-plan) recite the abstract idea itself (mental process of iterative plan revision informed by retrieved information).
Step 2B — Significantly More Considered individually and as an ordered combination, the additional elements do not amount to significantly more than the abstract idea. The generic processor, machine-readable data format, generic testcase generators, generic chat interface, and generic communication channel are each well-understood, routine, and conventional computing components. See MPEP § 2106.05(d); Alice, 573 U.S. 208; Mortgage Grader, Inc. v. First Choice Loan Servs. Inc., 811 F.3d 1314 (Fed. Cir. 2016). The recited data operations — receiving inputs, generating a plan, executing code, comparing outputs, generating test cases, identifying causes of failure, and refining code — are well-understood, routine, and conventional operations in the software development and software testing arts. Applicant's own Spec [0041]–[0042] characterizes the first testcase generator as a conventional "Black Box Test Case Generator" and the second testcase generator as a conventional "White Box Test Case Generator." Spec [0055] similarly describes the root-cause identification as being performed by a "debugger" that "systematically investigates the encountered errors, inconsistencies, or unexpected outcomes" — a description of conventional debugging. See also the prior-art references cited in the 35 U.S.C. 103 rejection below (Li sections 7.1, 7.2.1, 7.2.3 disclosing conventional test-case generation, unit testing of code paths, and GPT-4-based inspection of compilation and runtime errors; Reflexion sections 3 and 4.3 disclosing conventional self-reflection-based identification of failure causes and iterative refinement using self-generated unit tests; and Zhang § III-D disclosing conventional natural-language planner iteration on the plan based on user feedback).
The ordered combination does not add any inventive concept beyond the sum of its parts. The claim recites the sequence: receive → plan → generate code → test with black-box tests → test with white-box tests → identify root cause on failure → refine → iterate. This sequence is precisely the conventional software-development-and-testing workflow, applied on a generic computer. For at least the foregoing reasons, claims 1–5, 8–15, and 18–20 are directed to an abstract idea without significantly more, and are ineligible under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 9-15 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. ("A Study on Training and Developing Large Language Models for Behavior Tree Generation", hereinafter Li – previously presented) in view Noah Shinn et al. ("Reflexion: Language Agents with Verbal Reinforcement Learning", hereinafter Reflexion). With respect to claim 1 (Currently Amended), Li teaches a system, comprising: a processor configured to (Li discloses the BTGen Agent system implemented on computing hardware (Li, Section 6.3 "Our BTGen Agent," pages 19–20; Section 6.4 "Application," page 20 describing the back-end services as "the computational backbone of the system — processing complex requests and returning results"). Processor-based implementation is inherent in LLM inference and the disclosed back-end services.): receive an input comprising goal information to achieve a first sub- skill, and requirement information to achieve a goal for the first sub- skill (Li, Section 2.0 "Methodology," page 2, discloses receiving a task description as input to the BT generation function "BT = G(task)," wherein the task description carries both goal content and requirement content: "[e]xtracting relevant information for generation, such as task objectives, robot hardware capabilities, and environmental constraints, is particularly challenging when the task description is provided in unconstrained natural language form." Li, Section 6.1 "Prompt Engineering," page 15, reinforces this teaching: "A well-designed prompt should clearly outline the objectives of the agent, the environmental factors, and any behavioral constraints." The task objectives read on the recited goal information; the environmental factors and behavioral constraints read on the recited requirement information.) generate a machine readable meta-plan based on the received input, wherein the machine readable meta-plan is indicative of a set of sequential tasks that define a sequence of tasks and interdependencies required to accomplish the goal defined in the goal information (Li, Section 2.0 "Methodology," page 2, discloses: "Task Planning decomposes the complex task into multiple subtasks and organizes them in BT generation. Task planning requires converting abstract semantic instructions into detailed actionable sub-tasks and organizing them in the correct order. Specifically, it decomposes high-level goals into simpler manageable sub-tasks and organizes their control and information flows into the structure of a BT." Li, Section 6.2.3 "Planning Module," page 17, further discloses: "The planning module amalgamates LLMs' advanced planning abilities with classic planning algorithms, facilitating the transformation of user-supplied task descriptions to execution BTs." Machine-readability is expressly disclosed at Li, Section 4.1 "BT Data" (Data Schema), page 8: "XML Representation: An XML-formatted representation encapsulates the structural and node-specific details of the BT, facilitating both human readability and machine parsability." The recited "interdependencies" between the sequential sub-tasks read on the "control and information flows" disclosed in Li Section 2.0.) generate a first executable logic based on the generated machine readable meta-plan (Li, Section 4.1 "BT Data" (Data Schema), page 8, discloses that the BT schema includes an "Implementations" field that "delineates the concrete code implementations for the behavior encapsulated by each node." Li, Section 6.2.2 "Action Module," page 17, further teaches that BT nodes are "integral segments of code that direct the operations of robotics or artificial intelligence agents." Under applicant's express definition (Spec [0052] — "first executable logic may include a prompt, code, tool or combination thereof"), the BT (structural XML plus node code implementations) reads on the recited first executable logic, generated based on the planning module's meta-plan (Li Section 6.2.3).) iteratively refine the generated first executable logic to obtain a refined executable logic based on a validation operation, wherein, in the validation operation, when the first executable logic is executed, an output dataset is generated and compared with an outcome specified by the goal and the requirement information such that in each iteration of a refinement of the generated first executable logic, one or more errors or inconsistencies in the first executable logic are removed (Li, Section 6.3 "Our BTGen Agent," page 20, discloses: "The refinement in our BTGen Agent … is a mechanism that ensures the correct execution of the BT generation task by incorporating feedback from the simulation. The refinement occurs at multiple levels…. Additionally, the execution of the BTs is necessary for the final output. During the validation stage, it evaluates whether the final BTs can achieve the target goal. The evaluation results may lead to discarding the generated behavior and initiating a new generation." Li, Section 7.0 "Verification and Validation," pages 20–24, and Fig. 7, disclose the iterative BT-Simulator feedback loop in which the BT is executed by the simulator, the simulator produces environment states and actions as the output dataset, the output dataset is compared against the target goal, and feedback drives regeneration of the BT with errors from the prior iteration removed.) generate a set of testcases based on the first sub-skill to test and validate the first executable logic (Li, Section 7.2.3 "LLM-Based V&V," page 23, discloses: "Test cases generation from LLMs is a practical scenario of LLM-based V&V to aid the software development," and describes: "(1) Generate interview-style programming questions by prompting LLaMA-2 and de duplicate the set of questions. (2) Generate unit tests and ten Python solutions by prompting Code LLaMA. (3) Run the unit tests on the ten solutions and add the first solution that passes the tests to the self-instruct dataset." Li, Section 7.2.1 "Unit-Tests-Based V&V," page 22, further discloses: "unit tests can be constructed to test the correct execution of the BTs itself. These tests can verify that the tree traversal is happening correctly, that nodes are being executed in the proper order, and that the correct branches are taken based on different conditions.") generate, using a first testcase generator, one or more primary testcases of the set of testcases, wherein the first testcase generator generates a set of first input-output pairs without accessing the generated first executable logic (Li, Section 7.2.3 "LLM-Based V&V," page 23, step (1) discloses generating programming questions (input-output specifications) before any solution exists — "Generate interview-style programming questions by prompting LLaMA-2." Because step (1) occurs before any candidate Python solution is generated in step (2), the generator that produces these questions necessarily generates input-output pairs without access to any generated executable logic. Li, Section 7.1 "V&V for Abilities of BTGen Models," pages 20–21, and Fig. 5, further discloses HumanEval-style test cases in which "[e]ach problem in HumanEval … provides a prompt with descriptions of the function to be generated, function signature, and example test cases in the form of assertions." These test cases are defined based on the function specification (the first sub-skill) without access to the generated executable logic.) and generate, using a second testcase generator, one or more secondary testcases of the set of testcases, wherein the second testcase generator generates a set of second input-output pairs while accessing the generated first executable logic (Li, Section 7.2.3 "LLM-Based V&V," page 23, discloses: "[188] employs GPT-4 as an inspector for compilation and runtime error. If errors are found, the inspector provides suggestions for corrections." The inspector necessarily accesses the generated code in order to detect compilation and runtime errors and generate input-output pairs that exercise those error conditions. Li, Section 7.2.1 "Unit-Tests-Based V&V," page 22, further discloses tests that target specific internal structural elements of the BT — "tree traversal is happening correctly, that nodes are being executed in the proper order, and that the correct branches are taken based on different conditions" — which are generated with knowledge of (i.e., while accessing) the BT structure.). Li is silent to disclose; however, in an analogous art, Reflexion teaches wherein when the first executable logic fails on either of the one or more primary testcases or the one or more secondary testcases upon execution, one or more root causes leading to the failure are identified (Reflexion, Section 1 "Introduction," page 2, discloses: "Generating useful reflective feedback is challenging since it requires a good understanding of where the model made mistakes (i.e. the credit assignment problem) as well as the ability to generate a summary containing actionable insights for improvement." Reflexion, Section 3 "Reflexion: reinforcement via verbal reflection" — Self-Reflection subsection, page 4, further discloses: "Given a sparse reward signal, such as a binary success status (success/fail), the current trajectory, and its persistent memory mem, the self-reflection model generates nuanced and specific feedback…. For instance, in a multi-step decision-making task, when the agent receives a failure signal, it can infer that a specific action a_i led to subsequent incorrect actions a_{i+1} and a_{i+2}. The agent can then verbally state that it should have taken a different action." This is expressly the identification of root causes leading to the failure. Reflexion, Section 4.3 "Programming," page 7, applies the same self-reflection to code failures against unit tests: an example self-reflection reads "[the code was] wrong because it only checks if the total count of open and close parentheses is equal … [and does not check the] order of the parentheses," identifying the specific cause of failure.) and wherein a subsequent version of the first executable logic is refined to address the identified one or more root causes (Reflexion, Algorithm 1 "Reinforcement via self-reflection" (Figure 2), page 4, discloses the iterative loop in which each new trajectory τ_t is generated using the accumulated self-reflections sr_0 through sr_{t-1}, such that each subsequent version addresses the causes identified in prior iterations. Reflexion, Section 4.3 "Programming," page 7, discloses the code-refinement loop: unit tests are generated, code is generated and executed against the tests, self-reflection identifies why the code failed, and the code is regenerated in the next iteration incorporating the self-reflection. Reflexion Table 3 "Ablation study," page 8, confirms that omission of the self-reflection step (removal of root-cause identification) reduces pass@1 accuracy from 68% to 60%, demonstrating that the subsequent-version refinement is causally driven by the identified root causes.)
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the BTGen Agent framework of Li to incorporate the self-reflection-based root-cause identification and iterative refinement mechanism of Reflexion, and one of ordinary skill in the art would have had a reasonable expectation of success in doing so, for at least the following reasons.
First, Li and Reflexion are in the same field of endeavor: LLM-based agent frameworks that generate executable logic from natural-language task specifications and iteratively refine the executable logic through validation feedback. Both references address the same core technical problem — improving the accuracy and reliability of LLM-generated executable logic — and both adopt an iterative-refinement solution driven by execution feedback.
Second, Li itself acknowledges a deficiency that Reflexion is directly designed to remedy. Li, Section 6.3 "Our BTGen Agent," page 20, characterizes its in-generation refinement as "fast, inexpensive, but not entirely accurate," and Li, Section 6.2.5 "Refinement: beside Agent," pages 18–19, expressly identifies frameworks (e.g., Reflexion) that "promote recursive self-improvement" as relevant to improving the accuracy of the refinement process. Li thus provides express motivation to look to Reflexion for improving the accuracy of the BTGen Agent's iterative refinement.
Third, Reflexion Table 3 "Ablation study," page 8, provides empirical evidence establishing a reasonable expectation of success: the paper demonstrates that adding self-reflection-based root-cause identification to iterative code refinement improves pass@1 accuracy from 60% (without self-reflection) to 68% (with self-reflection) on the HumanEval Rust benchmark, and Reflexion Table 1 shows an improvement from 80.1% (GPT-4 baseline) to 91.0% pass@1 on HumanEval Python with the full Reflexion approach. A person of ordinary skill in the art would have recognized these empirical improvements as demonstrating that Reflexion's approach reliably enhances iterative code refinement, providing a reasonable expectation of success when applied to Li's BTGen Agent.
Fourth, the combination is the combination of prior-art elements according to their established functions to yield predictable results. Li's BTGen Agent already contains the requisite structure (planning module, action module, memory module, refinement mechanism, verification and validation pipeline), and Reflexion's self-reflection module is designed as a modular component that can be added to existing LLM-agent frameworks (Reflexion, Section 3, page 3). Combining them requires no more than applying Reflexion's self-reflection module to Li's existing verification loop. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007).
Accordingly, claim 1 would have been obvious under 35 U.S.C. § 103 over Li in view of Reflexion.
With respect to claim 2 (Currently Amended), Li teaches wherein a first iteration of the validation operation has a first relevance to the first sub-skill and a second iteration of the validation operation has a second relevance to the first sub-skill (As noted in the 35 U.S.C. 112(b) rejection above, claim 2 is indefinite; for purposes of applying prior art, the limitation is treated as being met by any two iterations of the validation operation, each having some relationship to the first sub-skill. Li teaches this limitation. Li, Section 2.0 "Methodology," page 2, discloses that successive iterations of BT generation each have some relationship to the target task, as the algorithm "iteratively develops S_t into intermediate BTs that function yet may not entirely align with predefined objectives." Each intermediate BT (each iteration) has some relationship to the target sub-skill. Li, Section 6.3 "Our BTGen Agent," page 20, confirms that refinement occurs across multiple iterations, each with its own relationship to the target goal.)
With respect to claim 3 (Original), Li teaches wherein the processor is configured to receive the input from another sub-skill from a component of the system (Li, Section 2.0 "Methodology," page 2, discloses that task planning "decomposes high-level goals into simpler manageable sub-tasks and organizes their control and information flows into the structure of a BT." The "information flows" between sub-tasks disclose receipt of input at one sub-skill (sub-task) from another sub-skill. Li, Section 6.3 "Our BTGen Agent," pages 19–20, further discloses that the Planning Module operates on outputs received from other modules (components) of the system: "It leverages outputs from the Memory Module and employs MCTS and CoT algorithms to build precise and effective trees.") With respect to claim 4 (Original), Li teaches wherein, in order to iteratively refine the generated first executable logic, the processor is further configured to revise the first executable logic by incorporating a feedback from the validation operation and re-executing the validation operation (Li, Section 7.2.3 "LLM-Based V&V," page 23, discloses: "[188] employs GPT-4 as an inspector for compilation and runtime error. If errors are found, the inspector provides suggestions for corrections. The process iterates until either the code passes inspection or a maximum number of inspections is reached." This discloses incorporating feedback from the validation operation into a revised version of the executable logic and re-executing the validation. Li, Section 7.0 "Verification and Validation," pages 20–24, and Fig. 7, further disclose the BT simulator feedback loop that provides a feedback message to the LLM for regeneration of the BT code, which is then re-executed by the simulator.)
With respect to claim 5 (Currently Amended), Li teaches wherein each of the set of testcases comprises an input-output pair based on the first sub-skill (Li, Section 7.1 "V&V for Abilities of BTGen Models," pages 20–21, and Fig. 5, disclose that each test case comprises an input-output pair based on the relevant task. The HumanEval example depicted in Fig. 5 shows a test case consisting of an input (function signature and description, e.g., incr_list([1, 2, 3])) and the expected output ([2, 3, 4]). Each such input-output pair is defined based on the task (the first sub-skill).)
With respect to claim 9 (Original), Li teaches wherein the processor is further configured to retrieve data from a communication channel to identify relevant information to generate the first executable logic (Li, Section 6.2.1 "Memory Module," pages 16–17, discloses: "we can integrate a Retrieval-Augmented Generation (RAG) system, similar to how human memory works. This combines LLM with a database, letting the model access fresh and relevant information beyond what it learned initially." The database from which relevant information is retrieved reads on the recited communication channel, and the retrieved information is used by the model to generate the BT (the first executable logic). Li, Section 6.2.2 "Action Module," page 17, further confirms that the retrieved information is used in generating the executable logic: "Retrieval-Augmented Generation (RAG) can facilitate the identification of optimal nodes. This approach leverages insights gleaned from expansive databases to recommend prime nodes while generating new contextual information.")
With respect to claim 10 (Currently Amended), Li teaches wherein the processor is further configured to utilize the identified relevant information to iteratively refine the machine readable meta-plan (Li, Section 2.0 "Methodology," page 2, discloses the iterative state transition in Equation 3: S_{t+1} = f_MCTS(S_t, f_RAG(S_t)), in which each successive plan state S_{t+1} is derived from the prior state S_t using the retrieved information f_RAG(S_t). Li, Section 6.2.3 "Planning Module," pages 17–18, further discloses: "By incorporating RL, the module iteratively optimizes tree generation based on feedback from the agent's interactions with its environment, consequently enhancing plan quality and efficiency.")
With respect to claim 11, claim 11 recites limitations similar to claim 1 in method form and is rejected for the same reasons set forth for claim 1 (Li, Sections 2.0, 4.1, 6.1, 6.2.2, 6.2.3, 6.3, 6.4, 7.0, 7.1, 7.2.1, 7.2.3, Fig. 5, Fig. 7; Reflexion, Sections 1, 3, 4.3, Algorithm 1, Table 3).
With respect to claims 12-15 and 19-20 recite limitations similar to claims 2-5 and 9-10 respectively, in method form, and are rejected for the same reasons set forth for their respective system-claim counterparts (Li citations as identified for each corresponding system claim above).
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. ("A Study on Training and Developing Large Language Models for Behavior Tree Generation", hereinafter Li) in view Noah Shinn et al. ("Reflexion: Language Agents with Verbal Reinforcement Learning", hereinafter Reflexion) and further in view of Chaoyun Zhang et al. ("AllHands: Ask Me Anything on Large-scale Verbatim Feedback via Large Language Models", hereinafter Zhang).
With respect to claim 8 (Currently Amended), Li teaches wherein the processor is further configured to: receive a first user feedback on the refined executable logic in a natural language via a chat interface coupled to the system (Li, Section 3.0 "Foundation Models," pages 4–6, discloses that the BTGen Agent is built on foundation LLMs including "ChatGPT," a "conversation model" that "exhibits superior capacities in communicating with humans" and "accurately tracing the context in multi-turn dialogues," which reads on the recited chat interface for receiving user input in natural language. Li, Section 6.4 "Application," page 20, further discloses that the Front-end User Interface "is architected to offer an intuitive, streamlined user engagement with BTs," through which users can "iterate over the development cycle, optimizing the BTs for deployment," reading on receipt of user feedback on the refined executable logic (BT) via the chat interface.) Li in view of Reflexion is silent to disclose; however, in an analogous art, Zhang teaches regenerate the machine readable meta-plan based on the goal information and the requirement information of the first sub-skill and the received first user feedback (Zhang, Section III-D "'Ask Me Anything' with an LLM-based QA Agent — Planner," pages 4–5, discloses: "when a user submits a query, the planner employs ICL to dissect the request into several sub-tasks using LLMs, and assigns specific code generator (CG) queries to each sub-task, producing executable code. The generated code is executed by the code executor and produce results. The planner evaluates whether the results adequately address the user's query. If the results are unsatisfactory or if the original query is ambiguous, the planner iterates on its plan, possibly requesting further clarification from the user. This iterative process continues until the user query is resolved.". This limitation is met by Zhang as follows: (i) "regenerate the machine readable meta-plan" is taught by Zhang's disclosure that "the planner iterates on its plan"; (ii) "based on the goal information and the requirement information of the first sub-skill" is taught by Zhang's disclosure that the planner's iteration is anchored in the user's originally-submitted query (which per Zhang Section III-D contains the goal and requirements to be resolved — "the planner employs ICL to dissect the request into several sub-tasks"); and (iii) "and the received first user feedback" is taught by Zhang's disclosure that the planner iterates "possibly requesting further clarification from the user," wherein the user's natural-language response provides the feedback that drives the plan regeneration until "the user query is resolved.")
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to further modify the Li-in-view-of-Reflexion combination to incorporate the natural-language-driven iterative planner of Zhang, and one of ordinary skill in the art would have had a reasonable expectation of success in doing so, for at least the following reasons.
First, all three references are in the same field of endeavor: LLM-based agent frameworks that receive natural-language input from users, generate a plan, produce executable logic from the plan, and iteratively refine the executable logic and/or plan based on validation feedback. Li discloses the BTGen Agent framework with chat-based user interaction (Li Sections 3.0, 6.4) and iterative refinement (Li Sections 6.3, 7.0). Zhang discloses the same paradigm applied to a natural-language question-answering agent that iterates on its plan when results are unsatisfactory or the user provides clarification (Zhang Section III-D). A person of ordinary skill in the art would recognize Zhang's planner architecture as directly applicable to Li's BTGen Agent workflow.
Second, Li itself contemplates natural-language interaction and iteration but does not explicitly tie natural-language user feedback to plan regeneration. Li Section 6.4 "Application," page 20, teaches that the Front-end UI "empower[s] users to efficiently iterate over the development cycle," providing express motivation to incorporate a mechanism by which user feedback drives plan iteration. Zhang provides exactly this mechanism: "If the results are unsatisfactory or if the original query is ambiguous, the planner iterates on its plan, possibly requesting further clarification from the user" (Zhang Section III-D, page 5). A POSITA seeking to implement Li's contemplated user-iteration cycle would look to Zhang's explicit disclosure.
Third, the combination is the combination of prior-art elements according to their established functions to yield predictable results. Zhang's planner-driven iteration on the plan is a modular architectural pattern (Zhang Section III-D describes the planner, code generator, and code executor as separate architectural components) that can be applied to any LLM-agent framework that already possesses a planner and executor — as Li's BTGen Agent does. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007). Zhang expressly describes the architecture as enabling the system to "manage complex queries by leveraging LLMs for both comprehension and code generation" (Zhang Section III-D, page 4), providing an established basis for reasonable expectation of success.
Accordingly, claim 8 would have been obvious under 35 U.S.C. § 103 over Li in view of Reflexion, and further in view of Zhang.
With respect to claim 18, claim 18 recites limitations similar to claim 8 in method form and is rejected for the same reasons set forth for claim 8 (Li Sections 3.0, 6.4; Zhang Section III-D).
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 ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM.
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, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights