DETAILED ACTION
This action is responsive to Remarks and Claim Amendments filed May 11, 2026.
Claims 1, 8 and 18-20 have been amended. Claims 9-17 have been canceled.
Claims 1-20 are pending and are 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
The objection of figure 1 is withdrawn in view of applicant’s amendments.
The objection of claims 1-8 and 18-20 and the specification is withdrawn after further clarification during the interview on April 30, 2026.
The rejection of claims 18-20 under 35 U.S.C. 101 is withdrawn in view of applicant’s amendments.
Claim interpretation under 112(f) is withdrawn in view of applicant’s cancellation of claims 9-17.
The rejection of claims 4-5 and 9-17 under 112(b) is withdrawn in view of applicant’s cancellation of claims 9-17 and further clarification for claims 4-5.
The rejection of claims 13-17 under 112(a) is withdrawn in view of applicant’s cancellation of claims 9-17.
Response to Arguments
Applicant has argued that Chemnitz does not teach the newly added limitations of independent claims 1 and 18 (Remarks, pages 8-10). Applicant’s arguments have been fully considered and are persuasive. Therefore, the rejection is withdrawn. However, upon further consideration, a new ground of rejection is made as set forth in details below. See Bei Chen et al. (“CodeT: Code Generation with Generated Tests”), art being made of record as applied herein.
Claim Objections
Claims 1-8 and 18-20 objected to because of the following informalities: Clams 1 (and similar for claim 18) uses English and British spellings for “Behaviors” and “Behaviours”. Under 37 CFR 1.75 applicant is recommended to select one of those for better language consistency. Appropriate correction is required.
Dependent claims 2-8 and 19-20 do not overcome the deficiency of the base claim and, therefore, are objected for the same reasons as the base claim.
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.
Claim 8 is 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 8 recites "wherein verifying the generated implementation source code comprises utilizing one or more tests to determine an accuracy of the source code output.". There is insufficient antecedent basis for this limitation in the claim. Examiner suggest amending the claim to “to determine an accuracy of the implementation source code”, which matches the language of claim 20.
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-8 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Leon Chemnitz et al. ("Towards Code Generation from BDD Test Case Specifications: A Vision", hereinafter Chemnitz – previously presented) in view of Bei Chen et al. (“CodeT: Code Generation with Generated Tests”, hereinafter Chen).
With respect to claim 1 (Currently Amended), Chemnitz teaches a method for accelerating a software development process using Generative Artificial Intelligence (AI) and Behaviour Driven Development (BDD) (See Chemnitz, Abstract: "we aim to leverage these developments and introduce a novel approach to generating frontend component code for the popular Angular framework. We propose to do this using behavior-driven development test specifications as input to a transformer-based machine learning model." See also Chemnitz, page 1, Section I "Introduction," discussing the use of Artificial Intelligence and Machine Learning solutions to increase developer efficiency, and identifying behavior-driven development (BDD) as the testing methodology used in the proposed approach.), the method comprising: receiving a natural language description of expected behaviors of machine-readable code functionality (See Chemnitz, page 1, right column, second paragraph: "BDD is a practice that integrates natural language (NL) into test specifications to make them comprehensible for people with little or no technical background." See also Chemnitz, Figure 1, depicting a cucumber BDD test specification for a "Change password" feature, written in natural language statements such as "Given I am signed in," "When I go to the edit user page," and "Then I should see 'Password changed,'" which constitute a natural language description of the expected behaviors of the password-change software functionality). converting the natural language description into test scenarios using a Domain Specific Language (DSL) (See Chemnitz, page 2, left column, second paragraph: "For the test cases to be interpretable by these domain experts and stakeholders, the test case specification is usually realized with a domain-specific language (DSL) that integrates natural language and is executed by a specialized tool or framework (e.g. cucumber). An example of a BDD test case for the cucumber framework can be found in Figure 1." Figure 1 of Chemnitz depicts the natural language description of the password-change behavior expressed in the Gherkin DSL used by the cucumber framework, demonstrating the conversion of natural language into test scenarios using a DSL).
generating implementation source code based on the test scenarios (See Chemnitz, Abstract: "We propose to do this using behavior-driven development test specifications as input to a transformer-based machine learning model." See also Chemnitz, page 2, left column, first paragraph: "We propose a method to generate application code from test case specifications to further reduce the developer time needed in application development. Specifically, we aim to extract the relevant information needed for the generation of code from the specification of test cases adhering to behavior-driven development (BDD) standards." See also Section III "Method," which describes the generation of Angular Component implementation code from BDD test case specifications using a transformer-based machine learning model).
verifying the generated implementation source code (See Chemnitz, page 4, left column, Section III-C "Post-Processing": "we have a high amount of information regarding the desired output. We can leverage this and have our model generate code samples which we then execute the tests on in a sandboxed environment. Generated samples that do not meet all assertion criteria of our tests will be discarded and only the ones that do are presented to the user." See also Section III-D "Evaluation," which discloses verifying the generated implementation source code by executing test coverage analysis and computing min, max, and average branch and instruction coverage on test data). Chemnitz is silent to disclose, however in an analogous art, Chen teaches: submitting the test scenarios to a Generative Al to generate test code for executing the test scenarios (Chemnitz does not expressly teach the limitation of "submitting the test scenarios to a Generative AI to generate test code for executing the test scenarios." The concept of this limitation is the use of a generative AI to produce the test code itself from the test scenarios. Although Chemnitz teaches submitting BDD test specifications to a transformer-based language model (See Chemnitz, page 1, right column, third paragraph: "we propose an approach that further leverages the NLP capabilities of transformers for code generation by using BDD test specifications as input for the generation task"), the test specifications in Chemnitz are submitted to the model as input for generating implementation/component code, not for generating test code. Chemnitz is therefore conceptually silent on using a generative AI to generate the test code itself. Chen cures this deficiency. Chen teaches that the same pre-trained generative language model used for code generation can also be used to automatically generate test cases (i.e., test code) for a given programming problem by providing an instruction prompt that specifies the format of the test cases. See Chen, Abstract: "we propose a novel method, CodeT, that leverages the same pre-trained language models to automatically generate test cases for the code samples, thus reducing the human effort and increasing the coverage of the test scenarios." See also Chen, Section 1, third paragraph: "we propose to automatically generate test cases for arbitrary programming problems and use them to quickly verify any solution." See also Chen, Section 2.1 "Test Case Generation," which describes feeding the context c (containing the natural language problem description) along with an instruction p to the language model M to obtain a set of generated test cases Y = M(concat(c, p)), where the generated test cases are formatted as executable assert statements such as "assert has_close_elements([1.0, 2.0, 3.9, 4.0, 5.0, 2.2], 0.3) == True" (Chen, Figure 2)). generating data sets for the test scenarios using Generative Al based on the natural language description of expected behaviours, wherein the Generative AI generates the data sets in structured formats to drive behaviours (The concept of this limitation is the use of a generative AI to produce structured input/output data sets that drive the test scenarios. Chemnitz is silent on the generation of test data sets by a generative AI; in Chemnitz, test data filtering is performed using pre-existing assertion criteria rather than AI-generated data sets. Chen cures this deficiency. Chen teaches that the generative language model automatically generates test cases that are themselves structured input/output data sets. See Chen, Section 2.1 "Test Case Generation": "A test case is a pair of input and expected output for the function defined in the context." See also Chen, Section 2.1, describing the instruction prompt as comprising "an 'assert' statement to start the test case generation, which specifies the format of the test cases as input-output pairs." See also Chen, Figure 2, depicting the generated test case "assert has_close_elements([1.0, 2.0, 3.9, 4.0, 5.0, 2.2], 0.3) == True," in which the input list [1.0, 2.0, 3.9, 4.0, 5.0, 2.2] and threshold value 0.3 form a structured input data set, and the expected output True specifies the behavior that the function under test must produce, thereby driving the behavior of the function under test. The structured assert-statement form of the generated test cases is a structured format that incorporates AI-generated data sets to drive the expected behaviors of the function under test.) incorporating the generated data sets into descriptions of the test scenarios (The concept of this limitation is the inclusion of the AI-generated data sets within the descriptions of the test scenarios. As Chemnitz does not teach AI-generated data sets, Chemnitz is correspondingly silent on incorporating such data sets into test scenario descriptions. Chen cures this deficiency. As discussed above, Chen teaches that the test cases generated by the language model are formatted as assert statements that, by construction, incorporate the input data sets and expected output values directly within the description of each test case. See Chen, Section 2.1 and Figure 2, as discussed above. Each generated test case is itself the test scenario description that contains the AI-generated input/output data set as integral parts of the assert statement). wherein the Generative AI generates the test code and the data sets prior to generation of the implementation source code, such that the implementation source code is generated to pass the test scenarios that incorporate the AI-generated data sets (The concept of this limitation is that the AI produces the test code and the data sets, and the implementation source code is generated to satisfy those AI-generated tests with their AI-generated data sets. As Chemnitz does not teach AI-generated test code or AI-generated data sets, Chemnitz is necessarily silent on the implementation source code being generated to pass such AI-generated tests. Chen cures this deficiency. Chen teaches that the language model M generates both a set of code solutions X = M(c) and a set of test cases Y = M(concat(c, p)), and that the implementation code that is ultimately selected as the output of the process is the implementation code that passes the AI-generated test cases under the dual execution agreement procedure. See Chen, Figure 1 caption: "Both the code solutions and the test cases are generated by the pre-trained language model. The best code solution is then selected by a dual execution agreement." See also Chen, Section 2 (introduction): "we use M to generate test cases for the programming problem (Section 2.1), and then select the best code solution xˆ based on a dual execution agreement (Section 2.2)." See also Chen, Section 2.2 "Dual Execution Agreement": "we execute the code solution x on the test case y... If the code solution x can be executed without errors and the output matches the expected output, then we say the code solution x can pass the test case y." The implementation code that emerges as the output of Chen's method is, by construction, code that passes the AI-generated test scenarios incorporating the AI-generated input/output data sets). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the BDD-driven generative AI code generation framework of Chemnitz with the AI-generated test cases and dual execution agreement methodology of Chen. Both Chemnitz and Chen address the use of pre-trained generative language models to assist software development by generating code from natural language descriptions, and both references identify the quality and coverage of test cases as critical to evaluating the correctness of the generated implementation code. Chemnitz expressly teaches submitting BDD test specifications as input to a transformer-based machine learning model for implementation code generation but relies on pre-existing human-authored BDD test specifications. Chen expressly identifies the manual creation of test cases as "costly and time-consuming" (Chen, Abstract) and further states that "it is unrealistic to expect users to provide test cases for every problem they want to solve" (Chen, Section 1, third paragraph), and proposes the use of the same pre-trained generative language model to automatically generate test cases for verification of code solutions. One of ordinary skill in the art seeking to extend Chemnitz's BDD-driven code generation framework so that the entire BDD pipeline could be automated, rather than relying on human-authored test specifications, would have been motivated to apply Chen's approach of automatically generating test cases (with their structured input/output data sets) using the same generative language model, and to use the AI-generated tests both as the basis for generating the implementation code and as the criterion for selecting the implementation code per the dual execution agreement. The combination yields the method recited in claim 1 with predictable results and a reasonable expectation of success because Chemnitz already contemplates the use of transformer-based pre-trained language models trained on natural language and code (See Chemnitz, page 2, right column, Section II, identifying Codex, CodeBERT, and CodeT5 as suitable models for the proposed approach), and Chen demonstrates that the same class of pre-trained language models (including Codex) can be effectively employed to generate both test cases and code solutions in a unified framework (See Chen, Section 3 "Experimental Setup" and Section 4 "Experimental Results"). With respect to claim 2 (Original), Chemnitz teaches wherein the Generative Al is trained to generate [[the test code and the data sets]] based on the expected behaviors described in the natural language description (See Chemnitz, page 3, left column, Section III-A "Data Acquisition and Pre-Processing": "As stated at the beginning of this section, we need data for the training, testing, and validation of our model and we plan to extract this data from open-source projects on GitHub," disclosing training of the generative AI model on a dataset comprising natural language test specifications and corresponding code. See also Chemnitz, page 4, left column, Section III-B "Model": "Through the use of the Codex fine-tuning API, our data set can be used to train the model and customize it to our needs," disclosing that the generative AI is trained to generate output based on the natural language descriptions of expected behaviors comprising the BDD test specifications. See also Chemnitz, Abstract and Section III, disclosing that the trained model generates its output based on the natural language description of expected behaviors set forth in the BDD test specifications). Chemnitz is silent to disclose, however in an analogous art, Chen teaches: the test code and the data sets (The concept of this part of the limitation is that the output of the trained generative AI includes the test code and the structured input/output data sets, rather than only implementation code. Chemnitz trains its generative model to produce implementation code (Angular component code) from BDD test specifications, and is conceptually silent on training the model to produce test code and data sets. Chen cures this deficiency. Chen teaches that the pre-trained generative language model is used to generate test cases (test code) that consist of input values and expected output values (data sets) from the natural language context describing the expected behaviors of the function under test. See Chen, Section 2.1 "Test Case Generation," as discussed in the rejection of claim 1 above; the language model M generates the set of test cases Y = M(concat(c, p)) where context c contains the natural language problem description of expected behavior, and each generated test case is structured as an assert statement comprising input values and an expected output value (See also Chen, Figure 2).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the BDD-driven generative AI code generation framework of Chemnitz with the AI-generated test cases and dual execution agreement methodology of Chen. Both Chemnitz and Chen address the use of pre-trained generative language models to assist software development by generating code from natural language descriptions, and both references identify the quality and coverage of test cases as critical to evaluating the correctness of the generated implementation code. Chemnitz expressly teaches submitting BDD test specifications as input to a transformer-based machine learning model for implementation code generation but relies on pre-existing human-authored BDD test specifications. Chen expressly identifies the manual creation of test cases as "costly and time-consuming" (Chen, Abstract) and further states that "it is unrealistic to expect users to provide test cases for every problem they want to solve" (Chen, Section 1, third paragraph), and proposes the use of the same pre-trained generative language model to automatically generate test cases for verification of code solutions. One of ordinary skill in the art seeking to extend Chemnitz's BDD-driven code generation framework so that the entire BDD pipeline could be automated, rather than relying on human-authored test specifications, would have been motivated to apply Chen's approach of automatically generating test cases (with their structured input/output data sets) using the same generative language model, and to use the AI-generated tests both as the basis for generating the implementation code and as the criterion for selecting the implementation code per the dual execution agreement. The combination yields the method recited in claim 1 with predictable results and a reasonable expectation of success because Chemnitz already contemplates the use of transformer-based pre-trained language models trained on natural language and code (See Chemnitz, page 2, right column, Section II, identifying Codex, CodeBERT, and CodeT5 as suitable models for the proposed approach), and Chen demonstrates that the same class of pre-trained language models (including Codex) can be effectively employed to generate both test cases and code solutions in a unified framework (See Chen, Section 3 "Experimental Setup" and Section 4 "Experimental Results"). With respect to claim 3 (Original), Chemnitz teaches wherein the Generative Al utilizes machine learning techniques to improve quality and accuracy of the generated implementation source code and the data sets over time (See Chemnitz, page 3, left column, Section III-A "Data Acquisition and Pre-Processing": "we need data for the training, testing, and validation of our model and we plan to extract this data from open-source projects on GitHub." See also Chemnitz, page 3, right column, discussing filtering criteria such as minimum number of test cases per file and project popularity to improve the quality of training data. See also Chemnitz, Section III-D "Evaluation," discussing iterative training across multiple models, computing CodeBLEU scores and instruction/branch coverage metrics, and improving model output quality through the use of these machine learning evaluation techniques). With respect to claim 4 (Original), Chemnitz teaches wherein the natural language description of expected behaviors description is based on product information (See Chemnitz, Figure 1, depicting a cucumber BDD test specifying a "Change password" feature, which constitutes a description of expected behavior based on product information about the password-change software product feature. See also Chemnitz, page 2, left column, discussing that BDD test specifications are written collaboratively with "domain experts and stakeholders," who provide product information that forms the basis of the natural language descriptions. Examiner notes: Given the broad scope of the claim term "product information," any natural language description of the expected behavior of a software product, including the password-change feature depicted in Chemnitz, Figure 1, falls within the scope of this limitation). With respect to claim 5 (Original), Chemnitz teaches wherein the natural language description of expected behaviors description is based on customer information (See Chemnitz, Figure 1, depicting a cucumber BDD test specifying customer-facing behavior including "Given I am signed in," "When I go to the edit user page," "And I press 'Change password,'" and "When I sign in with password 'newPassword,'" all of which describe expected behaviors based on customer information, such as user credentials, customer interactions with the user interface, and customer authentication states. Examiner notes: Given the broad scope of the claim term "customer information," any natural language description of expected behaviors involving customer-facing interactions or customer-related data, including the customer authentication and password-change behaviors depicted in Chemnitz, Figure 1, falls within the scope of this limitation). With respect to claim 6 (Original), Chemnitz teaches further comprising reviewing the generated implementation source code to ensure requirement compliance (See Chemnitz, page 4, right column, Section III-D "Evaluation": "To find an answer to RQ2 we suggest defining a threshold score that indicates whether a piece of code can be considered high quality when measured against a sample from the evaluation set." See also Chemnitz, Section III-D: "Another possible evaluation strategy would be to have a representative group of experienced developers that assess the quality of the generated code manually," disclosing review of the generated implementation source code to ensure compliance with the quality and behavioral requirements specified in the BDD test scenarios. See also Chemnitz, Section IV: "If our approach can successfully generate application code that satisfies the tests, the code has already passed quality assurance and is accepted from a business perspective," further disclosing the review of the generated code against the requirement specifications). With respect to claim 7 (Original), Chemnitz teaches wherein the implementation source code is generated without human intervention (See Chemnitz, page 2, left column, first paragraph: "We propose a method to generate application code from test case specifications to further reduce the developer time needed in application development. Specifically, we aim to extract the relevant information needed for the generation of code from the specification of test cases adhering to behavior-driven development (BDD) standards." See also Chemnitz, Section IV: "If our approach can successfully generate application code that satisfies the tests, the code has already passed quality assurance and is accepted from a business perspective, theoretically eliminating all initial programming work that deals with the implementation of actual application code." These passages disclose generation of the implementation source code by the machine learning model without human writing of the implementation code itself). With respect to claim 8 (Currently Amended), Chemnitz teaches wherein verifying the generated implementation source code comprises utilizing one or more tests to determine an accuracy of the source code output (See Chemnitz, page 4, left column, Section III-C "Post-Processing": "we have a high amount of information regarding the desired output. We can leverage this and have our model generate code samples which we then execute the tests on in a sandboxed environment. Generated samples that do not meet all assertion criteria of our tests will be discarded and only the ones that do are presented to the user," disclosing the use of one or more tests executed in a sandboxed environment to verify the generated implementation source code and determine whether the source code output meets the assertion criteria, i.e., to determine the accuracy of the source code output. See also Chemnitz, page 4, right column, Section III-D "Evaluation," describing the use of test coverage analysis and quality metrics to measure the accuracy of the generated source code output). With respect to claims 18-20, the claims are directed to a medium that corresponds to the method recited in claims 1 and 7-8, respectively (see the rejection of claims 1 and 7-8 above; wherein Chemnitz also teaches such system in figure 2 using an interface, e.g., a system must have memory).
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