Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This office action is in response to the application filed on 10/17/2024. Claims 1-20 are pending in this application. Claims 1, 9 and 17 are the independent claims.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to (an) abstract idea(s) without significantly more.
Regarding claim 1, the limitation “generating the test script [] that receives as input the specification of the new test strategy, [] generate test scripts based on technical documentation for a testing framework defined for the software solution and integration tests generated for the software solution”, as drafted, is a function that under its broadest reasonable interpretation, is an activity that encompasses a person reviewing the specification, evaluating the required tests, and selecting and writing instructions for performing those tests, including with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Step 2A, Prong One.
Under Prong Two, this judicial exception is not integrated into a practical application. The additional element “receiving a request to generate a test script for a new test strategy defined for a software solution, wherein the received request includes a specification of the new test strategy” does nothing more than add insignificant extra-solution activity to the judicial exception by receiving or gathering the information used to formulate the testing instructions. See MPEP § 2106.05(g).
The additional elements “large language model” and “executing the test script for the new test strategy to obtain output data, the output data including performance data for the software solution” are recited at a high level of generality and merely instructs the computer to apply the mental process and obtain the resulting performance information. Accordingly, this element amounts to mere instructions to apply the exception using a computer. See MPEP § 2106.05(f). The recitation of a “computer-implemented method” identifies the computer environment in which the activity is performed and, without further meaningful limitations, does not integrate the exception into a practical application. See MPEP §§ 2106.05(f) and 2106.05(h).
Under Step 2B, the claim does not include additional elements sufficient to amount to significantly more than the judicial exception. As discussed above, “receiving a request to generate a test script for a new test strategy defined for a software solution, wherein the received request includes a specification of the new test strategy” the courts have identified merely sending and receiving data/information is well-understood, routine and conventional activity. See MPEP 2106.05(d). The “large language model”, including the recited training information, is used as a tool to perform the script-generation activity, and executing the resulting script instructs the computer to apply the generated instructions and obtain performance information. See MPEP § 2106.05(f). The computer-implementation requirement does not independently supply an inventive concept. Therefore, the additional elements do not amount to significantly more than the judicial exception and do not provide an inventive concept. Accordingly, claim 1 is not patent eligible under 35 U.S.C. § 101.
Regarding claim 2, the limitation “generating a test strategy [] based on technical documentation for the software solution, a test strategy template, and legacy test strategies defined for the software solution, wherein the technical documentation includes a portion associated with the new feature of the software solution”, recites an additional mental process under Prong One.
The additional element “receiving a request to execute a test for a new feature of the software solution, wherein the received request includes a specification of the new feature” adds additional insignificant extra-solution activity by receiving or gathering information. See MPEP §§ 2106.05(g) and 2106.05(d). The additional requirement of “executing a large language model to automatically generate one or more test strategies” merely recite instructions to implement an abstract idea on a generic computer or merely uses a generic computer or computer components as a tool to perform/apply the abstract idea, which is neither a practical application under Prong 1, nor amount significantly more under Step 2B.
Regarding claims 3 and 4, the additional limitations “wherein the obtained output data includes performance data for the new feature, wherein the performance data is generated based on criteria for monitoring performance of the new feature according to the generated test strategy” and “wherein the performance data include data defining inaccurate output data from the software solution based on input data provided during the execution of the test script,” respectively, further specify the information obtained through execution of the test script. These limitations add data-gathering activity without specifying a particular monitoring mechanism or technological improvement. See MPEP §§ 2106.05(g) and 2106.05(d). Considered individually and in combination with their respective inherited limitations, these additional elements neither integrate the judicial exception into a practical application under Prong Two nor amount to significantly more under Step 2B.
Regarding claim 5, the limitations “evaluating the performance data to determine an error in performance of a given feature of the software solution” and “determining a modification for a portion of software code of the software solution to adjust the performance of the given feature to match expected performance as defined in the new test strategy” recite additional mental processes under Prong One.
Regarding claim 6, the limitation “test script is generated to test one or more of i) functionality of the software solution, ii) security level, iii) performance with regard to time and resource utilization, and iv) accessibility and localization compliance” further limits the subjects addressed by the script-generation activity identified in claim 1. Selecting testing instructions directed to these subjects involves additional evaluation and judgment under Prong One.
The additional element “providing the test script for storing and executing through a testing framework” generally link the use of judicial exception to a particular technological environment or field of use which is neither a practical application under Prong 1, nor amount significantly more under Step 2B.
Regarding claim 7, the limitation “in response to obtaining test results from executed tests based on a set of test scripts by the testing framework, the set of test scripts including the provided test script, evaluating the obtained test results to determine one or more tests scripts that had failed; and obtaining data descriptive of executions of the one or more test scripts that had failed.” recites an additional mental process under Prong One.
Regarding claim 8, “determining that a test script of the one or more test scripts is executed successfully” recites an additional mental process under Prong One.
The additional element “submitting the test script for use when testing functionality of the software solution at the testing framework” adds additional insignificant extra-solution activity by receiving or gathering information. See MPEP §§ 2106.05(g) and 2106.05(d). Considered individually and in combination with the inherited limitations, this element neither integrates the judicial exception into a practical application under Prong Two nor amounts to significantly more under Step 2B.
Regarding claim 9, the limitation “generating the test script [] that receives as input the specification of the new test strategy, [] generate test scripts based on technical documentation for a testing framework defined for the software solution and integration tests generated for the software solution”, as drafted, is a function that under its broadest reasonable interpretation, is an activity that encompasses a person reviewing the specification, evaluating the required tests, and selecting and writing instructions for performing those tests, including with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Step 2A, Prong One.
Under Prong Two, this judicial exception is not integrated into a practical application. The additional element “receiving a request to generate a test script for a new test strategy defined for a software solution, wherein the received request includes a specification of the new test strategy” does nothing more than add insignificant extra-solution activity to the judicial exception by receiving or gathering the information used to formulate the testing instructions. See MPEP § 2106.05(g).
The additional elements “large language model” and “executing the test script for the new test strategy to obtain output data, the output data including performance data for the software solution” are recited at a high level of generality and merely instructs the computer to apply the mental process and obtain the resulting performance information. Accordingly, this element amounts to mere instructions to apply the exception using a computer. See MPEP § 2106.05(f). The recitation of a “system comprising: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform operations” identifies the computer environment in which the activity is performed and, without further meaningful limitations, does not integrate the exception into a practical application. See MPEP §§ 2106.05(f) and 2106.05(h).
Under Step 2B, the claim does not include additional elements sufficient to amount to significantly more than the judicial exception. As discussed above, “receiving a request to generate a test script for a new test strategy defined for a software solution, wherein the received request includes a specification of the new test strategy” the courts have identified merely sending and receiving data/information is well-understood, routine and conventional activity. See MPEP 2106.05(d). The “large language model”, including the recited training information, is used as a tool to perform the script-generation activity, and executing the resulting script instructs the computer to apply the generated instructions and obtain performance information. See MPEP § 2106.05(f). The system requirement does not independently supply an inventive concept. Therefore, the additional elements do not amount to significantly more than the judicial exception and do not provide an inventive concept. Accordingly, claim 9 is not patent eligible under 35 U.S.C. § 101.
Regarding claims 10-16, these claims recite limitations corresponding respectively to claims 2-8. For the corresponding limitations, see the analyses of claims 2-8 above. The recitation of the limitations in the context of a system having a processor and memory does not alter the eligibility analysis, as the processor and memory merely provide computer implementation and a technological environment in which the recited judicial exceptions are performed. See MPEP §§ 2106.05(f) and 2106.05(h). Thus, claims 10-16 do not integrate the judicial exception into a practical application under Step 2A, Prong Two, and do not recite significantly more under Step 2B.
Claims 9-16 are additionally rejected as “one or more computer-readable memories” under their broadest reasonable interpretation in light of the specification may be interpreted as including non-transitory storage means and therefore directed to non-statutory subject matter.
Regarding claim 17, the limitation “generating the test script [] that receives as input the specification of the new test strategy, [] generate test scripts based on technical documentation for a testing framework defined for the software solution and integration tests generated for the software solution”, as drafted, is a function that under its broadest reasonable interpretation, is an activity that encompasses a person reviewing the specification, evaluating the required tests, and selecting and writing instructions for performing those tests, including with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Step 2A, Prong One.
Under Prong Two, this judicial exception is not integrated into a practical application. The additional element “receiving a request to generate a test script for a new test strategy defined for a software solution, wherein the received request includes a specification of the new test strategy” does nothing more than add insignificant extra-solution activity to the judicial exception by receiving or gathering the information used to formulate the testing instructions. See MPEP § 2106.05(g).
The additional elements “large language model” and “executing the test script for the new test strategy to obtain output data, the output data including performance data for the software solution” are recited at a high level of generality and merely instructs the computer to apply the mental process and obtain the resulting performance information. Accordingly, this element amounts to mere instructions to apply the exception using a computer. See MPEP § 2106.05(f). The recitation of a “non-transitory, computer-readable medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations” identifies the computer environment in which the activity is performed and, without further meaningful limitations, does not integrate the exception into a practical application. See MPEP §§ 2106.05(f) and 2106.05(h).
Under Step 2B, the claim does not include additional elements sufficient to amount to significantly more than the judicial exception. As discussed above, “receiving a request to generate a test script for a new test strategy defined for a software solution, wherein the received request includes a specification of the new test strategy” the courts have identified merely sending and receiving data/information is well-understood, routine and conventional activity. See MPEP 2106.05(d). The “large language model”, including the recited training information, is used as a tool to perform the script-generation activity, and executing the resulting script instructs the computer to apply the generated instructions and obtain performance information. See MPEP § 2106.05(f). The computer-readable medium requirement does not independently supply an inventive concept. Therefore, the additional elements do not amount to significantly more than the judicial exception and do not provide an inventive concept. Accordingly, claim 9 is not patent eligible under 35 U.S.C. § 101.
Regarding claims 18-20, these claims recite limitations corresponding respectively to claims 2-4. For the corresponding limitations, see the analyses of claims 2-4 above. The recitation of the limitations in the context of a non-transitory, computer-readable medium does not alter the eligibility analysis, as the processor and memory merely provide computer implementation and a technological environment in which the recited judicial exceptions are performed. See MPEP §§ 2106.05(f) and 2106.05(h). Thus, claims 18-20 do not integrate the judicial exception into a practical application under Step 2A, Prong Two, and do not recite significantly more under Step 2B.
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.
Claims 1, 4, 9, 12, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Roper et al. (WO 2025/042771 A2) in view of Chavan et al. (US 2024/0012747 A1).
Per claim 1, Roper teaches the computer-implemented method comprising:
receiving a request to generate a test script for a new test strategy defined for a software solution
p. 63 para. 3 "The methods and systems described herein include an AI-assisted testing automation approach for a DE platform, where ML models are used to generate test scenarios for a given user input, and are subsequently used to create test scripts for testing a target piece of written code or software, whether it be for the frontend or the backend."
Generating a test scenario that is later used to create test scripts corresponds to generating a test script for a new test strategy defined for a software solution.
wherein the received request includes a specification of the new test strategy
p. 70 para. 2 "The scenario generation AI model 1410 then generates different human readable test scenarios 1412 based on these inputs. The goal is to create a variety of scenarios that a QA engineer might need to test, essentially simulating different user behaviors and sequences of actions."
The scenario (used to generate test scripts) contains information on what software functions to test corresponds to a specification of the new test strategy.
generating the test script based on executing a large language model that receives as input the specification of the new test strategy, wherein the large language model is trained to automatically generate test scripts based on technical documentation for a testing framework defined for the software solution,
p. 71 para. 2 "The test script generation process 1502 involves feeding the human-readable test scenarios 1503, UI components and their corresponding XPath mappings 1506, and training data into a script generation AI model 1508 (e.g., an LLM such as GorillaLLM)."
p. 71 para. 1 "Upon approval of the test scenarios, the test module proceeds to create automation scripts using different programming languages like Java or Python. These scripts are created to be compatible with common automation frameworks like SELENIUM, CYPRESS, and TESTNG."
The test being generated to be compatible with “SELENIUM…” shows the scripts are using testing frameworks to implement their functions.
p. 93 para. 5 "In order to train and/or fine-tune the Al models 2332, 2350, and 2354, the training module 2340 may use training and tuning data 2342 which may include sample user action data, sample test scenarios, sample test scripts, generated/updated scripts including template scripts, test script parameters, APIs, documentation, and other relevant training data."
Training the output of the script generator (LLM) based on relevant APIs and documentation corresponds to training the large language model to automatically generate test scripts based on technical documentation for a testing framework.
executing the test script for the new test strategy to obtain output data, the output data including performance data for the software solution.
p. 72 para. 3-4 "Once the scripts have been executed, test reports 1610 are generated. These reports provide a detailed account of the test execution, including information about which tests passed, which tests failed, and any errors or issues that were encountered during the testing process.These test reports can then be used for further analysis and improvement of the target software. They can provide valuable insights into the performance and effectiveness of the automation scripts, as well as highlight any potential issues or bugs in the software or application being tested."
Test reports containing performance indicators for the scripts correspond to output data including performance data for the software solution.
Roper does not explicitly teach:
wherein the large language model is trained to automatically generate test scripts based on integration tests
However, Chavan does teach:
wherein the large language model is trained to automatically generate test scripts based on integration tests
¶0029-0030 "The system 200 starts with multiple test protocols 202 (e.g., unit test, integration test, system test, end-to-end test) that are collectively input to a test orchestration engine 204, which can create a unitary test protocol 210 that obviates the need for the multiple test protocols 202. ...[0030] In one example, the ML model is generated based on a knowledgebase of testing protocols and verifications for multiple features of multiple application programs."
Using integration-test protocols as part of the testing information upon which an ML based test-generation model operates corresponds to training a large language model to automatically generate test scripts based on integration tests.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add training the AI model “based on integration tests” as taught by Chavan to the LLM test script generator training method of Roper because both references concern automated generation of software tests, and doing so would predictably expand Roper’s generated tests to cover interactions between software components, thereby increasing test coverage.
Per claim 4, Roper further teaches the method of claim 1, wherein:
The performance data include data defining inaccurate output data from the software solution based on input data provided during the execution of the test script.
p. 72 para. 3-4 "Once the scripts have been executed, test reports 1610 are generated. These reports provide a detailed account of the test execution, including information about which tests passed, which tests failed, and any errors or issues that were encountered during the testing process.These test reports can then be used for further analysis and improvement of the target software. They can provide valuable insights into the performance and effectiveness of the automation scripts, as well as highlight any potential issues or bugs in the software or application being tested."
The reports contain information on errors during testing which correspond to inaccurate output data from the software solution.
Claim 9 is rejected for the same reasons as claim 1, as it recites the system corresponding to the method of claim 1.
Claim 12 is rejected for the same reasons as claim 4, as it recites the system corresponding to the method of claim 4.
Claim 17 is rejected for the same reasons as claim 1, as it recites the computer-readable medium limitations corresponding to the method of claim 1.
Claim 20 is rejected for the same reasons as claim 4, as it recites the computer-readable medium limitations corresponding to the method of claim 4.
Claims 2-3, 10-11 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Roper and Chavan in view of Bragaia et al. (US 2025/0103471 A1) further in view of Clement et al. (US 2024/0419917 A1).
Per claim 2, Roper further teaches the method of claim 1, comprising:
generating a test strategy by executing a large language model to automatically generate one or more test strategies
p. 73 Step 3 "Using the training data, the scenario generation AI model identifies patterns, high-risk areas, and recurring issues. Through such fine-tuning, the generative scenario generation AI model automatically generates test scenarios that aim to capture similar bugs."
Model (LLM) that automatically generates test scenarios corresponds to executing a large language model to automatically generate one or more test strategies.
Roper and Chavan fail to disclose:
receiving a request to execute a test for a new feature of the software solution, wherein the received request includes a specification of the new feature
generate one or more test strategies based on technical documentation for the software solution, a test strategy template, and legacy test strategies defined for the software solution, wherein the technical documentation includes a portion associated with the new feature of the software solution.
However, Bragaia does teach:
receiving a request to execute a test for a new feature of the software solution, wherein the received request includes a specification of the new feature
¶0033 "a user may wish to generate test cases for a software feature they have developed. Accordingly, the user can initiate the process by providing a first input 108 to the chat interface 104. The first input 108 can include a first natural language description 110 that identifies the software feature and defines an expected functionality of the software feature."
The input identifying the software feature and defining its expected functionality corresponds to the request to execute a test including a specification of the new feature.
Bragaia also fails to disclose:
generate one or more test strategies based on technical documentation for the software solution, a test strategy template, and legacy test strategies defined for the software solution, wherein the technical documentation includes a portion associated with the new feature of the software solution.
However, Clement teaches:
generate one or more test strategies based on technical documentation for the software solution, a test strategy template, and legacy test strategies defined for the software solution, wherein the technical documentation includes a portion associated with the new feature of the software solution.
¶0003 "A customized prompt generation service automates prompts to a large language model to perform a specific software engineering task. The service stores the custom data of a client that includes code changes to the codebase of the client in the form of code diff hunks, source code segments of the source code files of the codebase, code reviews, repaired code, and unit tests associated with the source code files of the codebase of the client. Prompt templates are associated with each software engineering task that include the requisite information needed for the large language model to perform the target task and generate a relevant output. A prompt to a large language model includes examples of the software engineering task from the customized data of the client of the service."
The prompts containing code reviews and repaired code correspond to the test strategies being based on technical documentation for the software solution.
The prompt generation service having multiple prompt templates corresponds to the test strategies being based on a test strategy template.
The prompts containing unit tests associated with the source code files correspond to the test strategies being based on legacy test strategies.
The prompts containing the code diff hunks and the source code corresponds to the technical documentation includes a portion associated with the new feature as the new features code would be disclosed in the code diff.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “receiving a request to execute a test for a new feature of the software solution, wherein the received request includes a specification of the new feature; generate one or more test strategies based on technical documentation for the software solution, a test strategy template, and legacy test strategies defined for the software solution; wherein the technical documentation includes a portion associated with the new feature of the software solution.” By modifying the test scenario generation process of Roper and Chavan to receive a feature-specific test request as taught by Bragaia and to generate the LLM input using a task-specific prompt template, software-specific context, and previously generated tests as taught by Clement. This would predictably provide the model with additional feature-specific context and relevant prior testing examples, thereby improving the relevance and accuracy of the generated test strategies (Clement ¶0001).
Per claim 3, Roper further teaches the method of claim 2, wherein:
The obtained output data includes performance data for the new feature, wherein the performance data is generated based on criteria for monitoring performance of the new feature according to the generated test strategy.
p. 72 para. 3-4 "Once the scripts have been executed, test reports 1610 are generated. These reports provide a detailed account of the test execution, including information about which tests passed, which tests failed, and any errors or issues that were encountered during the testing process.These test reports can then be used for further analysis and improvement of the target software. They can provide valuable insights into the performance and effectiveness of the automation scripts, as well as highlight any potential issues or bugs in the software or application being tested."
The test scripts generated (for the new feature) are used to produce a test report that includes the errors or issues that were encountered during the testing process of the feature being tested which corresponds to generating performance data based on criteria for monitoring performance of the new feature.
Claim 10 is rejected for the same reasons as claim 2, as it recites the system corresponding to the method of claim 2.
Claim 11 is rejected for the same reasons as claim 3, as it recites the system corresponding to the method of claim 3.
Claim 18 is rejected for the same reasons as claim 2, as it recites the computer-readable medium corresponding to the method of claim 2.
Claim 19 is rejected for the same reasons as claim 3, as it recites the computer-readable medium corresponding to the method of claim 3.
Claims 5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Roper and Chavan in view of Van der Vleuten (US 2025/0068547 A1).
Per claim 5, Roper and Chavan teach the method of claim 1 but fail to disclose:
evaluating the performance data to determine an error in performance of a given feature of the software solution; and determining a modification for a portion of software code of the software solution to adjust the performance of the given feature to match expected performance as defined in the new test strategy.
However, Van der Vleuten does teach:
evaluating the performance data to determine an error in performance of a given feature of the software solution; and determining a modification for a portion of software code of the software solution to adjust the performance of the given feature to match expected performance as defined in the new test strategy.
¶0032 "In some aspects, if the generated program fails validation (e.g., the program caused errors to be generated and/or returned inaccurate results), the fine-tuning system 125 may prompt the machine learning model 105 to attempt to repair the code and/or to generate new code. For example, the fine-tuning system 125 may provide feedback (such as the generated error(s)) as input, allowing the machine learning model 105 to generate revised code. As discussed below in more detail, this revised code may comprise the originally generated code with revisions or repair attempts (e.g., modifications to the program) and/or may comprise entirely new code (e.g., the model may attempt to write an entirely new program)."
Providing feedback after detecting an error in the program to repair/replace the broken function corresponds to adjusting the performance of the given feature by modifying the code in response to an error in performance.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “evaluating the performance data to determine an error in performance of a given feature of the software solution; and determining a modification for a portion of software code of the software solution to adjust the performance of the given feature to match expected performance as defined in the new test strategy.” By applying Van der Vleuten’s automated code repair technique to the test results generated by Roper and Chavan such that, when execution of a test indicates that the software fails to produce an expected result, the detected failure is provided as feedback to generate a modification of the corresponding software code. This would predictably reduce the need for manual code repair by the QA or development teams.
Claim 13 is rejected for the same reasons as claim 5, as it recites the system corresponding to the method of claim 5.
Claims 6-7 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Roper and Chavan in view of Hwang et al. (US 2016/0026562 A1).
Per claim 6, Chavan further teaches the method of claim 1, wherein:
The test script is generated to test one or more of i) functionality of the software solution, ii) security level, iii) performance with regard to time and resource utilization, and iv) accessibility and localization compliance,
¶0001 "Software testing techniques include, but not necessarily limited to analyzing product requirements for completeness and correctness in various contexts like industry perspective, business perspective, feasibility and viability of implementation, usability, performance, security, and infrastructure considerations."
Testing for completeness and correctness in terms of security corresponds to testing the security level of the software solution.
Roper and Chavan fail to disclose:
wherein the method further comprises: providing the test script for storing and executing through a testing framework.
However, Hwang does teach:
wherein the method further comprises: providing the test script for storing and executing through a testing framework.
¶0038 "The testPlex (testPlex 300) may include one or more test systems 302 that may be running on the same or different operating systems and platforms. In some implementations, the number of test systems 302 may be equal to, or even greater than, the number of operating systems and platforms that the software application is targeted for. According to such an embodiment, it may be possible to separately execute tests against a software application for each of the operating systems and/or platforms that the software application is targeted for, using the several test systems 302. Automated test selection, execution and monitoring may be controlled by a test control system (testController 304), that may include a test repository (testRepository 306) and a set of control programs (testControl Programs 308). The test repository (testRepository 306) may include tests to be executed and their related data and metadata."
Automatically selecting and executing test scripts across multiple systems corresponds to providing the test script for storing and executing through a testing framework.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “wherein the method further comprises: providing the test script for storing and executing through a testing framework.” By modifying the testing process of Roper and Chavan to store and execute the generated test scripts through the centralized testing framework taught by Hwang. This would predictably facilitate centralized storage and automated cross-platform execution, thereby improving test coverage and software portability.
Per claim 7, Hwang further teaches the method of claim 6, comprising:
in response to obtaining test results from executed tests based on a set of test scripts by the testing framework, the set of test scripts including the provided test script, evaluating the obtained test results to determine one or more tests scripts that had failed;
¶0067 "4. Test case fail action. Test process 10 may associate and assign a test case fail action to a test case which may have failed within the test group. Actions to be taken if a test case in the test group fails include but are not limited to..."
Detecting a failed test case within a test group corresponds to evaluating the obtained test results to determine one or more tests scripts that had failed.
and obtaining data descriptive of executions of the one or more test scripts that had failed.
¶0091 "For each test case that has been executed within the test group, test process 10 may produce a test case log. Test case logs may be automatically loaded to a centralized test case log repository (not shown). […] The index data, along with the full log, may be placed in a database that can be queried. The database may be queried to view how many tests were executed, when they were executed and the results of the execution."
Logging the results of the test execution corresponds to obtaining data descriptive of executions of the one or more test scripts that had failed.
Claim 14 is rejected for the same reasons as claim 6, as it recites the system corresponding to the method of claim 6.
Claim 15 is rejected for the same reasons as claim 7, as it recites the system corresponding to the method of claim 7.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Roper and Chavan in view of Dhalait (US 2013/0159963 A1).
Per claim 8, Roper, Chavan, and Hwang teach the method of claim 7 but fail to explicitly disclose:
in response to determining that a test script of the one or more test scripts is executed successfully, submitting the test script for use when testing functionality of the software solution at the testing framework.
However, Dhalait teaches:
in response to determining that a test script of the one or more test scripts is executed successfully, submitting the test script for use when testing functionality of the software solution at the testing framework.
¶0031 "In the next phase of unit testing, execution of unit test load is done and actual output and expected output are compared. The unit test load comprises of object binaries, drive modules and application library code. All of these components work collaboratively to retrieve any code/design defect from the results. The application design and/or code are again modified accordingly. Lastly in the versioning phase using Star Team the test cases are checked in for further reusability."
¶0039 "The result generating module (403) reports the defects unveiled during comparison. The defects can be either design defects or logical defects in the code. These defects are reported back and iteratively the process is repeated until the test case passes."
Modifying the defective code (to run successfully) and subsequently checking the test case into a version management system for future reuse corresponds to in response to determining that a test script is executed successfully, submitting the test script for use when testing functionality of the software solution at the testing framework.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “in response to determining that a test script of the one or more test scripts is executed successfully, submitting the test script for use when testing functionality of the software solution at the testing framework.” By modifying the testing framework of Roper, Chavan, and Hwang such that a test script is submitted to the test repository for future execution after determining that the test script executes successfully, as taught by Dhalait. This would predictably ensure that test scripts stored for subsequent execution have already been successfully validated, thereby reducing the storage and subsequent execution of defective test scripts and improving the reliability of the test suite.
Claim 16 is rejected for the same reasons as claim 8, as it recites the system corresponding to the method of claim 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
(US 2025/0077682 A1) Dynamic generation of features based on software testing
Teaches: Automatic test script generation and logging the results wherein the AI model is trained on a “large corpus of automation scripts, software tests, scripting best practices, and the like”
(US 2023/0367703 A1) Automated software testing with reinforcement learning
Teaches: Simulating users’ interactions with an application for testing wherein the test scripts are generated from an AI model and are provided through a testing platform.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUKE THOMSON whose telephone number is (571)272-0511. The examiner can normally be reached Monday Friday, 9 a.m. 6 p.m. ET..
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, Chat Do can be reached at (571) 272-3721. 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.
/LUKE THOMSON/ Examiner, Art Unit 2193
/Chat C Do/ Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights