Prosecution Insights
Last updated: July 17, 2026
Application No. 18/462,353

TEST CASE GENERATION USING GENERATING ARTIFICIAL INTELLIGENCE

Non-Final OA §103
Filed
Sep 06, 2023
Examiner
PAULINO, LENIN
Art Unit
2197
Tech Center
2100 — Computer Architecture & Software
Assignee
The Toronto-dominion Bank
OA Round
3 (Non-Final)
57%
Grant Probability
Moderate
3-4
OA Rounds
1y 0m
Est. Remaining
83%
With Interview

Examiner Intelligence

Grants 57% of resolved cases
57%
Career Allowance Rate
192 granted / 335 resolved
+2.3% vs TC avg
Strong +26% interview lift
Without
With
+25.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 11m
Avg Prosecution
17 currently pending
Career history
368
Total Applications
across all art units

Statute-Specific Performance

§101
2.9%
-37.1% vs TC avg
§103
93.3%
+53.3% vs TC avg
§102
3.2%
-36.8% vs TC avg
§112
0.2%
-39.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 335 resolved cases

Office Action

§103
DETAILED ACTION Claims 1-12, 14-19, 21 and 22 are pending. Claims 1, 5, 6, 9, 14, and 17 have been amended. Claim 20 has been cancelled. Claim 22 is new. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This non-final office action is in response to the applicant’s response received on 04/13/2026, for the advisory office action mailed on 03/26/2026. Examiner’s Notes Examiner has cited particular columns and line numbers, paragraph numbers, or figures 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 from the applicant, in preparing the responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 4/13/2026 has been entered. Response to Arguments Applicant’s arguments filed 03/12/2026 regarding rejection made under 35 U.S.C. § 103 has been considered but are moot in view of new ground(s) rejection. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 1, 5, 6, 9, 14, 17 21 and 22 Raman et al. (US-PGPUB-NO: 2019/0370160 A1) hereinafter Raman, in further view of McClory et al. (US-PGPUB-NO: 2018/0321918 A1) hereinafter McClory. As per claim 1, Raman teaches an apparatus comprising: a memory; a processor coupled to the memory, the processor configured (see Raman paragraph [0093], “The computing device 1000 includes a processor 1002, a memory 1004, a storage device 1006, a high-speed interface 1008 connecting to the memory 1004 and multiple high-speed expansion ports 1010, and a low-speed interface 1012 connecting to a low-speed expansion port 1014 and the storage device 1006”) to: receive a request to test a software program by a test execution service, the request including a description of parameters of the test (see Raman paragraph [0038], “Beginning with requirements documentation, the described system generates test scenarios, which are used to create test cases once the application or system has been built. Requirements documentation (e.g., business requirements, functional requirements, use cases, user stories, and so forth) captures, for example, information related to the business process(es) that will be supported by the software, intended actions that will be performed through the software, managed data, rule sets, nonfunctional attributes (e.g., response time, accessibility, access and privilege), and so forth”); generate a test case including a sequence of steps and an automation script that comprises a step definition with mappings between the sequence of steps and corresponding code functions based on execution of a generative artificial intelligence (GenAI) model on the description (see Raman paragraph [0068], “By way of example, a test scenario or list of scenarios may be included in what is called a feature file, where a formatted language, such as Gherkin, is used to write the scenarios in a human readable way. Such a feature file may be used in the generation of an automated testing script for an automation tool. Example automation tools include Unified Functional Testing (UFT), Tricentis Tosca™, Worksoft Certify™, and Selenium™. The testing automation tool provides a framework that can be used to provide support software structures, such as step definitions, for each of the test scenarios. Step definitions act as skeleton placeholders where automation code blocks may be implemented”); scan the step definition to identify the corresponding code functions and automatically execute the corresponding code functions in sequence with the automation script (see Raman paragraph [0068], “For example, each step in a given scenario may map to a step definition. The automation code block is implemented for each step definition and executed when the scenario is run by the testing framework. The automation code block may be written in a variety of programming language, such as Ruby, C++, Java, Scala, Python, and so forth, selected based on system requirements. Once generated, the step definitions and respective code blocks, may be referred to as an automated testing script. The testing automation tool provides an execution environment for these generated scripts, which may be run for acceptance and/or regression testing”). Raman does not explicitly teach identify a programming language of the software program; connect the test execution service to a testing framework based on the identified programming language; and output results of performing the sequence of steps to a user interface. However, McClory teaches identify a programming language of the software program (see McClory paragraph [0151], “Method 600 begins at stage 602 by identifying a programming language from determined application creation configuration information, for example the determined application creation configuration information of method 500.”); connect the test execution service to a testing framework based on the identified programming language (see McClory paragraph [0153-0154], “At stage 606, API configuration information for an existing service used by the software application may be received, as discussed with respect to FIG. 1. For example, an application developer may desire to connect the new software application to existing services of an organization of which the developer is a part of The API configuration information for the service may include, without limitation, authentication information (e.g., an API key) to access the service and available methods for invoking the service. At stage 608, one or more methods may be defined based on the API configuration information and in the identified programming language that connect the application to endpoints of the existing service. These methods may include logic to make calls to the existing service as permitted by the service's API.”); automatically execute the sequence of steps on the software program with the automation script based on a software library of the testing framework (see McClory paragraph [0155], “At stage 610, code stubs may be generated within the generated source code files based on the received API configuration information. In an embodiment, each code stub enables access to the existing service by incorporating the methods defined at stage 608. For example, an application developer may place business logic of the application requiring use of the existing service within the generated code stubs, and each generated code stub may already include the necessary logic to call the existing service.”); and output results of performing the sequence of steps to a user interface (see McClory paragraph [0133], “In response to receiving the elicited approval from the development device associated with the designated user, execution of the testing workflow may proceed. In an embodiment, the results of each test may also direct the testing workflow to execute various branches within the workflow. For example, a failed test may prompt additional tests to be executed that would not otherwise be executed as part of the core testing workflow.”). Raman and McClory are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Raman’s teaching of generating and executing automated testing scripts with McClory’s teaching of integration, testing, orchestration and deployment of applications to incorporate being able to synchronize testing frameworks to software programs being developed in different programming languages, see McClory paragraphs [0006] “In an embodiment, a build of the application source code information may be initiated to generate the software application. An application infrastructure configured to host the software application may be provisioned in an infrastructure services provider system based on the application creation configuration information. Finally, the software application may be deployed to the application infrastructure upon generation of the software application”). As per claim 5, Raman modified with McClory teaches wherein the processor is further configured to generate a description of a plurality of actions to be performed during performance of the test case, and store the description of the plurality actions within a document in the memory (see Raman paragraph [0038], “Beginning with requirements documentation, the described system generates test scenarios, which are used to create test cases once the application or system has been built. Requirements documentation (e.g., business requirements, functional requirements, use cases, user stories, and so forth) captures, for example, information related to the business process(es) that will be supported by the software, intended actions that will be performed through the software, managed data, rule sets, nonfunctional attributes (e.g., response time, accessibility, access and privilege), and so forth”). As per claim 6, Raman modified with McClory teaches wherein the test case comprises perquisites, an objective, references, and the sequence of steps that are generated based on execution of the GenAI model on the description of the parameters of the test (see Raman paragraph [0038], “Beginning with requirements documentation, the described system generates test scenarios, which are used to create test cases once the application or system has been built. Requirements documentation (e.g., business requirements, functional requirements, use cases, user stories, and so forth) captures, for example, information related to the business process(es) that will be supported by the software, intended actions that will be performed through the software, managed data, rule sets, nonfunctional attributes (e.g., response time, accessibility, access and privilege), and so forth”). As per claims 9 and 14 these are the method claims to apparatus claims 1 and 6, respectively. Therefore, they are rejected for the same reasons as above. As per claim 17, this is the computer-readable medium comprising instructions stored therein which when executed by a processor cause the computer claim (see Raman paragraph [0095], “The instructions can also be stored by one or more storage devices such as computer- or machine-readable mediums (for example, the memory 1004, the storage device 1006, or memory on the processor 1002)”) to apparatus claim 1. Therefore, it is rejected for the same reasons as above. As per claim 21, Raman modified with McClory teaches wherein the processor is configured to generate code for running commands in a test environment of the framework, and include the code within the automation script (see Raman paragraph [0065], “For example, the automation accelerator engine 122 generates an automated testing script(s) from a provided test scenario and context file. The automation accelerator engine 122 extracts the intended interaction (intent) and relevant testing data from each test scenario through the employment of, for example, natural language processing (NLP) techniques. The intent is correlated to an appropriate test object(s) in the provided context file. For example, if the test scenario recites “Click on the Submit button,” the automation accelerator engine 122 parses the natural language and derives the context as “submit button,” which it then maps to the submit button object from the object map of the submitted context file. A template for the selected automation tool is applied to the extracted intent and data along with the correlated object(s) to generate the resulting automated testing script.”). As per claim 22, Raman modified with McClory teaches wherein the processor is configured to map a next step in the test case to a corresponding code function in the automation script and execute the corresponding code function (see Raman paragraph [0078], “The test generation model may generate test cases and test data, based on the application information, for testing the cloud application. In some implementations, each test case may include a series of tests to perform on the cloud application in order to test different aspects of the cloud application. Each test case may include a format that includes a test case identifier, test data for the test case, a test sequence for the test case, an expected result for the test case, an actual result for the test case, and/or status information associated with the test case. In some implementations, the test data may include data to be utilized by the test cases when testing the different aspects of the cloud application”). Claim(s) 2, 10 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Raman (US-PGPUB-NO: 2019/0370160 A1) and McClory (US-PGPUB-NO: 2018/0321918 A1), in further view of Augustine et al. (US-PGPUB-NO: 2015/0082287 A1) hereinafter Augustine. As per claim 2, Raman modified with McClory teaches wherein the processor is further configured to display on a display coupled to the memory and the processor the plurality of testing elements via a user interface (see Raman paragraph [0093], “The processor 1002 can process instructions for execution within the computing device 1000, including instructions stored in the memory 1004 or on the storage device 1006 to display graphical information for a GUI on an external input/output device, such as a display 1016 coupled to the high-speed interface 1008.”). Raman modified with McClory do not explicitly teach receive approval of the plurality of testing elements via the user interface, and in response to the received approval, generate the test case comprise the plurality of testing elements. However, Augustine teaches receive approval of the plurality of testing elements via the user interface, and in response to the received approval (see Augustine paragraph [0034], “In one implementation, the user may not be satisfied with the at least one test scenario. In such an implementation, the user may not approve the at least one test scenario, and the testing module 122 may receive, from the user, suggestions to modify and improve the at least one test scenario to be in conformance with the user requirements. Upon receiving the suggestions, the testing module 122 may revise the at least one test scenario, and may provide the revised test scenario to the user. Once the user is satisfied, the testing module 122 may receive the first approval from the user”), generate the test case comprise the plurality of testing elements (see Augustine paragraph [0035], “Upon receiving the first approval, the testing module 122 may create and associate one or more test cases with each step of the at least one test scenario. Further, the testing module 122 may provide the at least one test scenario along with the associated one or more test cases to the user. The user may confirm the validation of the one or more test cases, and may provide a second approval accordingly”). Raman, McClory and Augustine are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Raman’s teaching of generating and executing automated testing scripts and McClory’s teaching of integration, testing, orchestration and deployment of applications with Augustine’s teaching of scenario-based test design to incorporate having an approval process for testing elements within a test design see Augustine paragraph [0016], “In one implementation, following the creation of the at least one test scenario, the at least one test scenario may be provided to the user for approval. The user may verify the validity of the at least one test scenario, and subsequently may provide the first approval to proceed with further stages of the software testing. In one implementation, the verification may include confirming if the at least one test scenario captures the functionalities of the software application, as desired by the user. In an implementation, when the user is not satisfied with the at least one test scenario, the user may not approve the at least one test scenario and provide suggestions to modify and improve the at least one test scenario to be in conformance with the user requirements”). As per claim 10, this is the method claim to apparatus claim 2. Therefore, it is rejected for the same reasons as above. As per claim 18, this is the computer readable medium claim to apparatus claim 2. Therefore, it is rejected for the same reasons as above. Claim(s) 3, 4, 11, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Raman (US-PGPUB-NO: 2019/0370160 A1) and McClory (US-PGPUB-NO: 2018/0321918 A1), in further view of Pryzant et al. (US-PGPUB-NO: 2024/0330165 A1) hereinafter Pryzant. As per claim 3, Raman modified with McClory do not explicitly teach wherein the processor is further configured to generate and output a prompt on a user interface of the user device and receive a response to the prompt from the user interface of the user device. However, Pryzant teaches wherein the processor is further configured to generate and output a prompt on a user interface of the user device (see Pryzant paragraph [0100], “At operation 405, a first prompt (e.g., an attacker prompt) is generated for testing a test software. The first prompt includes features discussed above, such as an objective for testing the test software. At operation 410, the first prompt is provided as input to a first LLM that is operating as the actor/attacker (e.g., an LLM attacker)”) and receive a response to the prompt from the user interface of the user device (see Pryzant paragraph [0102], “At operation 425, a second prompt (e.g., an evaluator prompt) is generated for evaluating the responses from the test software. The second prompt may include features and content as discussed above. In some examples, the second prompt includes at least the responses from the software and/or the outputs from the first LLM. In other examples, the response from the software and/or the outputs form the first LLM may be provided to the second LLM separately. The second prompt may also include the first prompt as context for the objective set for the first LLM”). Raman, McClory and Pryzant are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Raman’s teaching of generating and executing automated testing scripts and McClory’s teaching of integration, testing, orchestration and deployment of applications with Pryzant’s teaching of quality assurance for digital technologies using large language models to incorporate having prompts to use on large language models for interaction with test software, see Pruzant paragraph [0004], ” To conduct the quality-assurance testing described herein, the LLM-based actor and/or an LLM-based evaluator may each interact with the test software. For example, based on prompts that may be generated by a computing system (and/or received from a user), the LLM-based actor generates inputs to the test software in an attempt to break or otherwise test the quality and/or security of the test software. The LLM-based evaluator then evaluates the responses from the test software to evaluate the quality and/or security of the test software. In this manner, with limited to no human interaction, the SAE technology tests the limits and discovers vulnerabilities, defects, and/or other issues with the test software, while evaluating safety, security, operationality, and/or user-friendliness of the test software, all in an automated manner.” As per claim 4, Raman modified with McClory and Pryzant teaches wherein the processor is further configured to generate the plurality of testing elements for the test case based on execution of the GenAI model on the prompt and the response to the prompt (see Pryzant paragraph [0105], “The first LLM may then generate updated outputs, based on the third prompt, to achieve the objective. The updated outputs are transmitted from the first LLM to the test software in operation 455. The test software generates updated responses, which are transmitted back to the first LLM in operation 460”). As per claims 11 and 12, these are the method claims to apparatus claims 3 and 4, respectively. Therefore, they are rejected for the same reasons as above. As per claim 19, this is the computer-readable medium claim to apparatus claim 3. Therefore, it is rejected for the same reasons as above. Claim(s) 7, 8, 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Raman (US-PGPUB-NO: 2019/0370160 A1) and McClory (US-PGPUB-NO: 2018/0321918 A1), in further view of Sharma et al. (US-PGPUB-NO: 2023/0251960 A1) hereinafter Sharma. As per claim 7, Raman modified with McClory do not explicitly teach wherein the processor is further configured to display the test case generated by the GenAI model on the user interface, and receive feedback about the test case via the user interface. However, Sharma teaches wherein the processor is further configured to display the test case generated by the GenAI model on the user interface, and receive feedback about the test case via the user interface (see Sharma paragraph [0097], “In some examples, the testing change may specifically be the addition of a new test step, but a relevant node (e.g., similar and redundant) may be identified within the graph data structure. That is, the new test step specified by the query is redundant with another test step, and in such an instance, a response may be provided to the query that includes a recommendation to use the existing test step. Likewise, the testing change may specifically be the addition of a new test case having certain test steps, and upon identification of an existing test case via segments of the graph data structure, a recommendation to use the existing test case may be provided. Accordingly, the minimization of redundancy through the graph data structure may continue to be provided as additional test steps and cases are requested”). Raman, McClory and Sharma are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Raman’s teaching of generating and executing automated testing scripts and McClory’s teaching of integration, testing, orchestration and deployment of applications with Sharma’s teaching of machine learning techniques for automated software testing configuration management to incorporate using a machine learning model and gathering input in order to generate test cases based on the testing changes and extracted features to produce more reliable and less redundant test cases, see Sharma paragraph [0103], “With identification of redundant test cases/steps through optimization of the graph data structure, redundant test cases/steps may be automatically removed from the test case repository and a notification may be provided to a user. In an example embodiment, the change report further indicates redundant test cases/steps that have been removed”. As per claim 8, Raman modified with McClory and Sharma teaches wherein the processor is further configured to train the GenAI model based on execution of the GenAI model on the test case and the received feedback about the test case (see Sharma paragraph [0102], “Meanwhile, the graph data structure and the test cases in general may be updated in accordance with the testing change. If the testing change indicates the addition of a new test step or a new test case, and if it is determined that the new test step or new test case is not redundant with any existing test step or test case using similarity measures and the graph data structure, then the new test step or the new test case may be accordingly added. In such examples, the graph data structure may be updated to reflect such additions. Upon enacting such changes, the unsupervised and/or the supervised machine learning models may be reconfigured and retrained in light of the changed testing aspects. With this, the change report may provide various metrics, including a number of test steps updated, a number of test steps deleted, a number of test steps added, a number of test cases changed, and/or the like, in various embodiments.”). As per claims 15 and 16, these are the method claims to apparatus claims 7 and 8, respectively. Therefore, they are rejected for the same reasons as above. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Venkataraman (US-PGPUB-NO: 2019/0196949 A1) teaches generating and executing automated testing scripts. Tang et al. (US-PGPUB-NO: 2025/0045185 A1) teaches large language models for creating a multi-lingual low-resource code translation dataset. aHhhHgfhuhgHart et al. (US-PGPUB-NO: 2024/0265281 A1) teaches providing software related answer based on a trained model. ZZZhang et al. (US-PGPUB-NO: 2024/0256423 A1) teaches program improvement using large language models. Haswell et al. (US-PGPUB-NO: 2005/0193269 A1) teaches synchronization of automated scripting framework. Yalla et al. (US-PGPUB-NO: 10,949,337 B1) teaches utilizing neural network and artificial intelligence models to select and execute test cases in a software development platform. Any inquiry concerning this communication or earlier communications from the examiner should be directed to LENIN PAULINO whose telephone number is (571)270-1734. The examiner can normally be reached Week 1: Mon-Thu 7:30am - 5:00pm Week 2: Mon-Thu 7:30am - 5:00pm and Fri 7:30am - 4:00pm EST. 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, Bradley Teets can be reached at (571) 272-3338. 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. /LENIN PAULINO/Examiner, Art Unit 2197
Read full office action

Prosecution Timeline

Sep 06, 2023
Application Filed
Aug 07, 2025
Non-Final Rejection mailed — §103
Oct 06, 2025
Response Filed
Jan 13, 2026
Final Rejection mailed — §103
Mar 12, 2026
Response after Non-Final Action
Apr 13, 2026
Request for Continued Examination
Apr 18, 2026
Response after Non-Final Action
Apr 30, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12681842
AUTOMATIC PORTABLE DEVICE TESTING METHOD AND SYSTEM
5y 1m to grant Granted Jul 14, 2026
Patent 12645575
API DRIVEN CONTINUOUS TESTING SYSTEMS FOR TESTING DISPARATE SOFTWARE
3y 7m to grant Granted Jun 02, 2026
Patent 12619415
CONFIGURATION MANAGEMENT FOR NON-DISRUPTIVE UPDATE OF A DATA MANAGEMENT SYSTEM
3y 7m to grant Granted May 05, 2026
Patent 12596635
BLACK-BOX FUZZING TESTING METHOD AND APPARATUS
2y 10m to grant Granted Apr 07, 2026
Patent 12541449
AUTOMATIC GENERATION OF ASSERT STATEMENTS FOR UNIT TEST CASES
2y 3m to grant Granted Feb 03, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
57%
Grant Probability
83%
With Interview (+25.8%)
3y 11m (~1y 0m remaining)
Median Time to Grant
High
PTA Risk
Based on 335 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month