DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 have been submitted for examination and are pending further prosecution by the United States Patent & Trademark Office.
Allowable Subject Matter
With respect to independent claim 1, the prior art of record does not teach or suggest, either solely or in combination, the limitations "based on the set of failure types and the set of requirements, generating a configuration file, wherein the configuration file comprises fixtures and validations, wherein the fixtures define acceptable ranges for each intermediate state of the software program and wherein the validations describe logical relations between two or more intermediate states of the software program during execution;" when considered in combination with the other limitations of claim 1.
With respect to independent claim 2, the prior art of record does not teach or suggest, either solely or in combination, the limitations "based on the set of failure types and the set of requirements, generating a configuration file, wherein the configuration file comprises fixtures and validations, wherein the fixtures define acceptable ranges for each intermediate state of the software program and wherein the validations describe logical relations between two or more intermediate states of the software program during execution;" when considered in combination with the other limitations of claim 2.
With respect to independent claim 14, the prior art of record does not teach or suggest, either solely or in combination, the limitations "based on the set of failure types and the set of requirements, generating a configuration file, wherein the configuration file comprises fixtures and validations, wherein the fixtures define acceptable ranges for each intermediate state of the software program and wherein the validations describe logical relations between two or more intermediate states of the software program during execution;" when considered in combination with the other limitations of claim 14.
Note, however, that claims 1-20 are rejected under 35 USC § 101 as being directed to an abstract idea.
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 without significantly more. Claim 1 recites a system for customizing a testing process for a software program. Under a broadest reasonable interpretation, claim 1 would fall under the category of mental processes as the claim features limitations performable as mental steps, with the assistance of pen & paper, but without additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea. An analysis of claim 1 according to the 2019 Revised Patent Subject Matter Eligibility test follows:
Step 1: Is the claim directed to a process, machine, manufacture or composition of matter?
Yes, claim 1 is directed to a system and, therefore, a machine.
Step 2A Prong 1: Does the claim recite an Abstract Idea, Law of Nature, or Natural Phenomenon?
Yes, claim 1 recites an abstract idea as the following limitations are performable as mental processes with the assistance of pen & paper: receiving a set of requirements for a software program, wherein the set of requirements is an Open API specification comprising logical rules linking one or more program states; - a developer can receive from a project manager, a requirements document containing a set of written requirements for a software program, where the requirements conform to the Open API specification and describe logical rules, such as required responses of the software program when given specific inputs; receiving a set of failure types that correspond to previous deviations from the logical rules in the set of requirements, wherein the set of failure types comprises syntax errors, functional errors, or performance defects; - the developer can receive from the project manager, examples of failure types, such as functional errors, encountered during preliminary testing of the software program, where said failure types deviated from one or more requirements within the set of written requirements; based on the set of failure types and the set of requirements, generating a configuration file, wherein the configuration file comprises fixtures and validations, wherein the fixtures define acceptable ranges for each intermediate state of the software program and wherein the validations describe logical relations between two or more intermediate states of the software program during execution;- -- using the failure types and set of requirements, the developer can create a written configuration file containing fixtures and validations, where fixtures describe a range of acceptable input values for intermediate functions of the software program, and where validations describe a logical relationship between two intermediate functions, such as a second function being executed only when a first function produces an output falling into a specified range; based on the configuration file, generating a plurality of test cases, wherein the plurality of test cases comprises parameters and endpoints generated based on the configuration file, wherein the parameters and endpoints describe values for intermediate states of the software program; - using the configuration file, the developer can create written test cases containing parameters and endpoints, wherein the parameters and endpoints describe values for intermediate functions of the software program;
Step 2A Prong 2: Does the Claim Recite Additional Elements That Integrate The Judicial Exception Into A Practical Application?
Claim 1 recites the additional elements of one or more non-transitory, computer-readable media comprising instructions that, when executed by the one or more processors perform the operations of the claim. However, as recited, the additional elements simply amount to using generic computing components to perform the abstract idea and, therefore, do not integrate the abstract idea into a practical application.
Claim 1 also recites the additional element of using the plurality of test cases, regulating the software program to produce output values from input values in accordance with the set of requirements, wherein the output values of the software program comprise verifications of approval decisions for resource access requests. Under a broadest reasonable interpretation, said regulation simply amounts to executing test cases against the software program to obtain output values from a resource, such as a storage, using input values as described in the set of requirements, and verifying the correctness of the returned output values. Said additional element amounts to an insignificant post-solution activity in the form of data outputting and, therefore, does not integrate the abstract idea into a practical application.
Step 2B: Does the Claim Recite Additional Elements That Amount To Significantly More Than The Judicial Exception?
Claim 1 recites the additional elements of one or more non-transitory, computer-readable media comprising instructions that, when executed by the one or more processors perform the operations of the claim. However, as recited, the additional elements simply amount to using generic computing components to perform the abstract idea and, therefore, do not amount to significantly more than the abstract idea.
Claim 1 also recites the additional element of using the plurality of test cases, regulating the software program to produce output values from input values in accordance with the set of requirements, wherein the output values of the software program comprise verifications of approval decisions for resource access requests. Under a broadest reasonable interpretation, said regulation simply amounts to executing the test cases against the software program to obtain output values from a resource, such as a storage, using input values as described in the set of requirements, and verifying the correctness of the returned output values. Said additional element amounts to an insignificant post-solution activity in the form of data outputting. Said additional element is also a well-understood, routine, conventional activity (see US 7779374 B1, col. 3:65-4:19, for example) and, therefore, is not significantly more than the abstract idea.
Claim 2, which recites a method for performing the operations of the system recited by analogous claim 1, is rejected for the same reasons given for claim 1. Since claim 2 lacks further additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea, the claim is ineligible.
Claim 3 is also directed to the abstract idea as the requirements document can contain a target performance metric for the software program, wherein the target performance metric is a numerical representation of a correctness of outputs of the software program. Since the claim lacks additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea, the claim is ineligible.
Claim 4 is also directed to the abstract idea as the limitation based on the configuration file, generating a plurality of test cases comprising parameters and endpoints generated based on the configuration file can be performed as a mental steps by the developer using the configuration file to create written test cases containing parameters and endpoints. The developer can also perform the limitation determining the software program reaches the target performance metric based on the output values as mental step by comparing output values generated by executing a test case against the software program with a target performance metric. Claim 4 also recites the additional element using the plurality of test cases, regulating the software program to produce output values from input values in accordance with the set of requirements. Under a broadest reasonable interpretation, said regulation simply amounts to executing the test cases against the software program to obtain output values based on input values as described in the set of requirements. Said additional element amounts to an insignificant post-solution activity in the form of data outputting. Said additional element is also a well-understood, routine, conventional activity (see US 7779374 B1, col. 3:65-4:19, for example) and, therefore, is not significantly more than the abstract idea.
Claim 5 recites the additional element of generating the set of failure types from failures from preliminary testing of the software program, wherein the set of failure types correspond to deviations from the set of requirements in the preliminary testing which, under a broadest reasonable interpretation, simply amounts to executing test cases against a software program and recording deviations from expected values. Said additional element amounts to an insignificant post-solution activity in the form of data outputting and, therefore, does not integrate the abstract idea into a practical application. Said additional element is also a well-understood, routine, conventional activity (see US 7779374 B1, col. 3:65-4:19, for example) and, therefore, is not significantly more than the abstract idea.
Claim 6 is also directed to the abstract idea as the following limitations are performable as mental processes with the assistance of pen & paper: generating a set of failed requirements based on the set of failure types and the set of requirements, wherein the set of failed requirements comprises logical relations in the set of requirements related to one or more failure types; - the developer can manually create written examples of requirements that failed, where said failed requirements correspond to failure types, such as functional errors; based on the set of failed requirements, determining fixtures and validations that would enforce the set of failed requirements; - based upon the failed requirements, the developer can manually determine fixtures and validations that would enforce the failed requirements; based on the fixtures and validations, generating the configuration file. - based upon the fixtures and validations, the developer can manually create the written configuration file. Since the claim lacks additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea, the claim is ineligible.
Claim 7 is also directed to the abstract idea as the limitation merely elaborates upon limitations found abstract in claim 2 without reciting one or more additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Claim 8 is also directed to the abstract idea as the limitation merely elaborates upon limitations found abstract in claim 2 without reciting one or more additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Claim 9 is also directed to the abstract idea as the limitation merely elaborates upon limitations found abstract in claim 2 without reciting one or more additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Claim 10 is also directed to the abstract idea as the limitation merely elaborates upon limitations found abstract in claim 2 without reciting one or more additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Claim 11 is also directed to the abstract idea as the following limitations are performable as mental processes with the assistance of pen & paper: using the fixtures of the configuration file, generating a plurality of parameters, wherein the plurality of parameters comprises input values for the software program; - the developer can generate parameters for the software program by manually selecting one or more input values from the range of fixtures in the configuration file; using the plurality of parameters and the validations of the configuration file, generating a plurality of intermediate states based on the logical relations from input values to intermediate states specified by the validations of the configuration file; - using the parameters and validations specified in the configuration file, the developer can manually generate expected output values of intermediate functions; using the plurality of intermediate states and the software program, generating a plurality of endpoints for the plurality of test cases. - using a range of fixtures for intermediate functions of the software program, the developer can manually derive endpoints for the test cases. Since the claim lacks additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea, the claim is ineligible.
Claim 12 recites the additional elements of causing the software program to process inputs corresponding to the parameters in the plurality of test cases and generate a first plurality of intermediate states and a first plurality of outputs; verify whether the first plurality of intermediate states and the first plurality of outputs satisfy requirements of the endpoints in the plurality of test cases; and in response to detecting one or more intermediate states or outputs not satisfying the requirements of the endpoints in the plurality of test cases, generating a notification comprising the one or more intermediate states or outputs. - These additional elements collectively amount to an insignificant post-solution activity in the form of data outputting and, therefore, do not integrate the abstract idea into a practical application. These additional elements are also well-understood, routine, and conventional activities (see US 7779374 B1, col. 3:65-4:19, for example) and, therefore, are not significantly more than the abstract idea.
Claim 13 is also directed to the abstract idea as the limitation merely elaborates upon limitations found abstract in claim 2 without reciting one or more additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Claim 14 is rejected for the same reasons given for analogous claim 1. While claim 14 recites the further additional elements of performing the operations of claim 1 using one or more non-transitory computer-readable media comprising instructions executed by one or more processors, said additional elements merely represent basic computing components and, therefore, amount to using a computer as a tool for performing the abstract idea. Thus, the additional elements do not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Claim 15 recites the additional element of generating the set of failure types from failures from preliminary testing of the software program, wherein the set of failure types correspond to deviations from the set of requirements in the preliminary testing. which, under a broadest reasonable interpretation, simply amounts to executing test cases against a software program and recording deviations from expected values. Said additional element amounts to an insignificant post-solution activity in the form of data outputting and, therefore, does not integrate the abstract idea into a practical application. Said additional element is also a well-understood, routine, conventional activity (see US 7779374 B1, col. 3:65-4:19, for example) and, therefore, is not significantly more than the abstract idea.
Claim 16 is also directed to the abstract idea as the following limitations are performable as mental processes with the assistance of pen & paper: generating a set of failed requirements based on the set of failure types and the set of requirements, wherein the set of failed requirements comprises logical relations in the set of requirements related to one or more failure types; - the developer can manually create written examples of requirements that failed, where said failed requirements correspond to failure types, such as functional errors; based on the set of failed requirements, determining fixtures and validations that would enforce the set of failed requirements; - based upon the failed requirements, the developer can manually determine fixtures and validations that would enforce the failed requirements; based on the fixtures and validations, generating the configuration file. - based upon the fixtures and validations, the developer can manually create the written configuration file. Since the claim lacks additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea, the claim is ineligible.
Claim 17 is also directed to the abstract idea as the limitation merely elaborates upon limitations found abstract in claim 14 without reciting one or more additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Claim 18 is also directed to the abstract idea as the limitation merely elaborates upon limitations found abstract in claim 14 without reciting one or more additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Claim 19 is also directed to the abstract idea as the limitation merely elaborates upon limitations found abstract in claim 14 without reciting one or more additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Claim 20 is also directed to the abstract idea as the limitation merely elaborates upon limitations found abstract in claim 14 without reciting one or more additional elements that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. WO 2009046525 A1 discloses a method and system for automated testing of hardware and software systems comprising the operations of creating an original grammar describing an initial set of test cases that can be run on a system under test (SUT), generating an original set of test cases using the grammar and a generator configuration file, applying the original set of test cases to the SUT, receiving and analyzing output from the SUT, such as by comparing the actual output from the SUT with the expected output for each test case, and creating a new set of grammars that isolate causes of failure of the SUT, where the new grammar may be modified to generate test cases that apply input values within a narrower range to the SUT. US 20070174713 A1 discloses a method for testing a command line interface of a software product featuring, in a first phase, generation of a scenarios matrix comprising test scenarios and acceptable ranges for CLI command arguments and, in a second phase, using the scenarios matrix to define test cases, each test case specifying execution of a selected command with desired values for arguments and expected results for verification. The NPL document "Minimizing Test cases in Rest API Fuzzing" discusses an approach for generating test cases based upon an OpenAI Specification and using the test cases to test REST API endpoints.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GEOFFREY R ST LEGER whose telephone number is (571)270-7720. The examiner can normally be reached M-F (IFP) ~9:00-5: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 571-272-6799. 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.
/GEOFFREY R ST LEGER/Primary Examiner, Art Unit 2192