DETAILED ACTION
Claims 1-20 are pending. Claims 1, 9 and 17 have been amended.
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 12/22/2025, for the final office action mailed on 10/22/2025.
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 01/22/2026 has been entered.
Response to Arguments
Applicant’s arguments filed 12/22/2025 have 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 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, 2, 9, 10, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Danthuluri et al. (US-PGPUB-NO: 2022/0100642 A1) hereinafter Danthuluri, in further view of Scholz et al. (US-PGPUB-NO: 2020/0183817 A1) hereinafter Scholz, Nishide (US-PGPUB-NO: 2010/0070937 A1); Guo et al. (US-PGPUB-NO: 2020/0311133 A1) hereinafter Guo, Heinecke et al. (US-PGPUB-NO: 2019/0317885 A1) hereinafter Heinecke and Vechev et al. (US-PGPUB-NO: 2012/0179650 A1) hereinafter Vechev.
As per claim 1, Danthuluri teaches a method for automating a test of a software system comprising a plurality of software services, the method comprising: defining a plurality of test steps, wherein each test step comprises one or more actions executed by a software service of the plurality of software services (see Danthuluri paragraph [0057], showing the creation of a test case comprising multiple methods (i.e. steps) for testing), wherein test input data is generated by previous test steps or system generated (see Danthuluri paragraph [0062], showing output values from previous methods being used as input values for subsequent methods in a sequence of execution); configuring a first test scenario at an information handling system executing an administrative console module of a test automation system, wherein the first test scenario comprises one or more test steps of the plurality of test steps (see Danthuluri paragraph [0058], showing the development of a test case (i.e., test scenario) which includes a number of REST methods (i.e., test steps)), and a first subset of the one or more test steps are chained to one another by passing output data from a first test step of the first subset as input data to a second test step of the first subset (see Danthuluri paragraph [0069], showing a sequence of tests being conducted and steps inheriting input values from the output values from a current method being executed (i.e., current test step)); executing the first test scenario at a test automation executor of the information handling system (see Danthuluri paragraph [0063], showing execution of the test case); configuring a second test scenario at the information handling system that includes one or more steps (see Danthuluri paragraph [0058], showing the development of a test case (i.e., test scenario) which includes a number of REST methods (i.e., test steps)), wherein a second subset of the one or more steps are chained to one another by passing output data from a first step of second subset as input data to a second test step of the second subset (see Danthuluri paragraph [0069], showing a sequence of tests being conducted and steps inheriting input values from the output values from a current method being executed (i.e., current test step)).
Danthuluri teaches the use of objects but does not explicitly teach wherein data of the plurality of test steps including expected results; the output data of the first test step is a first JavaScript Object Notation (json) object, wherein the second test step further receives as input data a second json object, the chained test steps pass group and field level data between test steps and test scenarios of more than one field from the first json object to the second json object and wherein step chaining enables data exchange between steps by passing json objects between test scenarios, wherein the passing of json objects provides for more than one field to be passed at a time. However, Scholz teaches wherein data of the plurality of test steps including expected results (see Sholz paragraph [0088], “Test suite 440 also incorporates test inputs 444, and expected test outputs 446. Test inputs 444 can be in common for all of the test datatypes 448, or can be partially or entirely customized for each respective test datatype 448. Expected test outputs 446 can be distinct for each respective test datatype, although they can be compressed in view of commonality in the expected outputs”); the output data of the first test step is a first JavaScript Object Notation (json) object, wherein the second test step further receives as input data a second json object, the chained test steps pass group and field level data between test steps and test scenarios of more than one field from the first json object to the second json object (see Sholz paragraph [0115-0117], “In a first way, test subtypes can be chained together. For example, a test subtype having child subtype L2T_X can be joined with another subtype having parent subtype L2T_X. The test subtypes can be chained in this way to reach from Level 1 to any leaf subtypes, and can also optionally be joined to a root field by matching the Level 1 subtype in FIG. 7B. Alternatively, chaining can be restricted to a preset maximum number of levels to limit testing complexity,” showing how a multi-level test datatypes can be defined from test subtypes which can be chained together, for example a JSON file portion with a level 1 subtype and 3 fields can inherit from a level 2 subtype) and passing json objects between the first test scenario and second test scenario (see Sholz paragraph [0117], “This subtype has Ls, Dt, and Rt all True, and En=False. (Rt is a constant attribute at level 1, always True, hence can be omitted from the level 1 subtype attributes in FIG. 7B, while Rt is not constant and can be retained at levels 2-4.) By merging redundant combinations, this level 1 subtype can have three fields (see FIG. 7F) with level 2 field (L2F) attributes L2F_LsImVs 782 (of which the Ls attribute is inherited from level 2 subtype L2T_Ls 783), L2F_LsDtMvCrRoVs 784 (of which the LsDt attributes are inherited from level 2 subtype L2T_LsDt 785), and L2F_DtIm 786 (of which the Dt attribute is inherited from level 2 subtype L2T_Dt 787)”) and wherein step chaining enables data exchange between steps by passing json objects between test scenarios (see Sholz paragraph [0121], “Some functionality, such as a user interface, can be satisfactorily tested directly using the definitions of datatypes. In other examples, a data object of an executable program can be passed to or made available to the software library to be operated on by a function of the software library. In such examples, the multi-level test datatypes can be instantiated as multi-level objects for testing”), wherein the passing of json objects provides for more than one field to be passed at a time (see Sholz paragraph [0122], “FIG. 9 is a flowchart 900 depicting a third example method according to the disclosed technologies, for testing with data objects. At process block 910 a set of attribute tuples can be determined, combinations of which are to be covered by testing. The attributes can be metadata attributes, inherited from the datatype of which the data object is an instance, or they can be data attributes. The tuples can be pairs or other N-tuples” and “In some examples, all attributes can be metadata attributes, and multi-level test objects can be constructed by building multi-level test datatypes as described in context of FIG. 6, and instantiating the datatypes as respective multi-level test objects”).
Danthuluri and Scholz 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 Danthuluri’s teaching of providing for the creation of test cases for web services testing automation with Scholz’s teaching for efficient combinatorial testing of multi-level datatypes and data objects to incorporate the use of JSON as a format to passing objects in test steps in order to provide flexibility in structuring the passage of data between steps within a test scenario.
Danthuluri modified with Scholz does not explicitly teach selected for checking assertions that include pointers to where information can be found within data sets that can be subject to an assertion formula or predetermined assertion. However, Nishide teaches selected for checking assertions that include pointers to where information can be found within data sets that can be subject to an assertion formula or predetermined assertion (see Nishide paragraph [0064], “The assertion converting section 14 of the assertion generating unit 12 scans the measurement point data 109 by following the next pointers to generate assertions 110 according to measurement description. In so doing, the assertion converting section 14 assigns assertion labels to the assertions 110 and adds the assigned assertion labels to the database. The assertion converting section 14 also adds coverage result areas for storing results of code coverage to the database”).
Danthuluri, Scholz and Nishide 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 Danthuluri’s teaching of providing for the creation of test cases for web services testing automation and Scholz’s teaching for efficient combinatorial testing of multi-level datatypes and data objects with Nishide’s teaching of code coverage measument point extracting unit which reads a device-under-test circuit description to incorporate usage of assertion pointers to gather information regarding the results, see Nishide paragraph [0071], “Finally, the assertion converting section 14 determines whether there is measurement point, that is, a measurement point label, that follows the "next" pointer (step S10). If there is a measurement point, that is, the determination is YES, the assertion converting section 14 returns to step S1, selects the measurement point label that follows the "next" pointer, and repeats the same process. On the other hand, if there is not a measurement point, that is, the determination is NO, the process will end”).
Danthuluri modified with Scholz and Nishide do not explicitly teach wherein the first and second json objects are common json objects providing agnostic mode of operation of service. However, Guo teaches wherein the first and second json objects are common json objects providing agnostic mode of operation of service (see Guo paragraph [0089], showing the use of json to share data between steps which is a data source-agnostic format.
Danthuluri, Scholz, Nishide and Guo 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 Danthuluri’s teaching of providing for the creation of test cases for web services testing automation, Scholz’s teaching for efficient combinatorial testing of multi-level datatypes and data objects and Nishide’s teaching of code coverage measument point extracting unit which reads a device-under-test circuit description with Guo’s teaching of implementing search index generator to incorporate the use of JSON as an agnostic format to make passing objects in test steps more efficient and easier.
Danthuluri modified with Scholz, Nishide and Guo do not explicitly teach desired test scenarios based on a testing pyramid of different levels of testing including level 1 unit testing, lever 2 integration testing and level 3 end-to-end testing. However, Heinecke teaches desired test scenarios based on a testing pyramid of different levels of testing including level 1 unit testing, lever 2 integration testing and level 3 end-to-end testing (see Heinecke paragraph [0103], showing the test type ratio being defined by a test pyramid the test pyramid showing the effort needed by each level of the pyramid, unit testing, integration testing and end-to-end testing and using a recommendation engine to recommend specific actions to be implemented in each testing area).
Danthuluri, Scholz, Nishide, Guo and Heinecke 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 Danthuluri’s teaching of providing for the creation of test cases for web services testing automation, Scholz’s teaching for efficient combinatorial testing of multi-level datatypes and data objects, Nishide’s teaching of code coverage measument point extracting unit which reads a device-under-test circuit description and Guo’s teaching of implementing search index generator with Heinecke’s teaching of automated quality assurance and software improvement to incorporate the use of test pyramid to better gauge what testing phase requires more testing and optimizing test actions.
Danthuluri modified with Scholz, Nishide, Guo and Heinecke do not explicitly teach executing assertion checks at various times, including before or after the execution of a step, or before or after execution of a test scenario. However, Vechev teaches executing assertion checks at various times, including before or after the execution of a step, or before or after execution of a test scenario (see Vechev paragraph [0024], “In the present disclosure, we present asynchronous assertions, assertions that are evaluated concurrently without stopping the application, but guarantee the same result as sequential evaluation. An efficient implementation of our technique in a system is referred to as STROBE. We also present an evaluation of STROBE on a number of realistic usage scenarios. Our results indicate that STROBE works well in practice: it scales almost perfectly over synchronous checking, and can execute a range of intensive assertion workloads with overheads under 2.times”).
Danthuluri, Scholz, Nishide, Guo, Heinecke and Vechev 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 Danthuluri’s teaching of providing for the creation of test cases for web services testing automation, Scholz’s teaching for efficient combinatorial testing of multi-level datatypes and data objects, Nishide’s teaching of code coverage measument point extracting unit which reads a device-under-test circuit description, Guo’s teaching of implementing search index generator and Heinecke’s teaching of automated quality assurance and software improvement with Vechev’s teaching of asynchronous assertions to incorporate the use of asynchronous assertions in order to reduce the cost of assertion checks when executing an application, see Vechev paragraph [0014], “In the present disclosure, we present asynchronous assertions. The idea behind asynchronous assertions in one embodiment is to allow assertion evaluation to proceed without stopping the application. With this approach, the program issues an assertion and immediately continues its execution, while another thread evaluates the assertion in the background. With asynchronous assertions, the cost of an assertion check is no longer imposed on the program runtime, thereby allowing developers to write arbitrarily complex assertions, and removing a significant roadblock towards making dynamic assertion checking practical”.
As per claim 2, Danthuluri modified with Scholz, Nishide, Guo, Heinecke and Vechev teaches further comprising: collecting assertion information associated with each of the one or more steps of the first test scenario (see Danthuluri paragraph [0062], showing the assertions being obtained after execution of the test case and sequence of methods); displaying a report comprising information associated with the assertion information. (see Danthuluri paragraph [0063], showing data indicating the test case status from the execution of the test cases and displaying to a user for analysis).
As per claims 9 and 10, these are the system claims to method claims 1 and 2, respectively. Therefore, they are rejected for the same reasons as above.
As per claims 17 and 18, these are the computer-readable medium claims to method claims 1 and 2, respectively. Therefore, they are rejected for the same reasons as above.
Claims 3-8, 11-16 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Danthuluri (US-PGPUB-NO: 2022/0100642 A1), Scholz et al. (US-PGPUB-NO: 2020/0183817 A1), Nishide (US-PGPUB-NO: 2010/0070937 A1), Guo (US-PGPUB-NO: 2020/0311133 A1), Heinecke (US-PGPUB-NO: 2019/0317885 A1) and Vechev (US-PGPUB-NO: 2012/0179650 A1), in further view of Chitgupakar et al. (US-PGPUB-NO: 2021/0318857 A1) hereinafter Chitgupakar.
As per claim 3, Danthuluri modified with Scholz, Nashide, Guo, Heinecke and Vechev do not explicitly teach wherein said configuring the first test scenario comprises: selecting a test step of the plurality of test steps; determining input data for the test step, wherein said input data comprises one or more of user interface data, data output from a previous test step, and data provided from a data store; selecting output data from the test step for an assertion check; selecting a data source for comparison in the assertion check; and determining when the assertion check is performed. However, Chitgupakar teaches wherein said configuring the first test scenario comprises: selecting a test step of the plurality of test steps; determining input data for the test step, wherein said input data comprises one or more of user interface data, data output from a previous test step, and data provided from a data store (see Chitgupakar paragraph [0025], showing the passing of json objects and test scenarios invoking user interface pages that will enable each test scenario to exchange data with other step; selecting output data from the test step for an assertion check; selecting a data source for comparison in the assertion check; and determining when the assertion check is performed (see Chitgupakar paragraph [0023], showing the creation of assertions from input test data and response payload along with using the assertions to perform various check points during the testing process).
Danthuluri, Scholz, Nishide, Guo, Heinecke, Vechev and Chitgupakar 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 Danthuluri’s teaching of providing for the creation of test cases for web services testing automation, Scholz’s teaching for efficient combinatorial testing of multi-level datatypes and data objects, Nishide’s teaching of code coverage measument point extracting unit which reads a device-under-test circuit description Guo’s teaching of implementing search index generator, Heinecke’s teaching of automated quality assurance and software improvement and Vechev’s teaching of asynchronous assertions with Chitgupakar’s teaching of enabling end-to-end testing of a variety of services having different modes of operation to incorporate having an assertion check in order to keep each step in the process validated.
As per claim 4, Danthuluri modified with Scholz, Nishide, Guo, Heinecke, Vechev and Chitgupakar teaches wherein said determining when the assertion check is performed comprises selecting whether the assertion check is performed prior to execution of the test step, subsequent to execution of the test step, or during execution of the test step (see Chitgupakar paragraph [0028], shows how assertion checks can be executed at various times, including before or after the execution of a step, or before or after execution of a test scenario.
As per claim 5, Danthuluri modified with Scholz, Nishide, Guo, Heinecke, Vechev and Chitgupakar teaches further comprising: configuring a second test scenario at the information handling system executing the administrative console module of the test automation system, wherein the second test scenario comprises one or more test steps of the plurality of test steps (see Danthuluri paragraph [0057], showing the creation of a test case comprising multiple methods (i.e. steps) for testing), and a second subset of the one or more test steps are chained to one another by passing output data from a first test step of the second subset as input data to a second test step of the second subset (see Danthuluri paragraph [0058], showing the development of a test case (i.e., test scenario) which includes a number of REST methods (i.e., test steps)), the output data of the first test step of the second subset is a third JavaScript Object Notation (json) object, wherein the second test step further receives as input data a fourth json object, the chaining passes group and field level data from the third json object to the fourth json object (see Chitgupakar paragraph [0032], showing a first step taking a response from a json object and similarly a second step can take the form as input a parent along with child json objects).
As per claim 6, Danthuluri modified with Scholz, Nishide, Guo, Heinecke, Vechev and Chitgupakar teaches further comprising: configuring a feature comprising the first test scenario and the second test scenario; chaining the first test scenario to the second test scenario by passing output data from the first test scenario as input data to the second test scenario (see Danthuluri paragraph [0008], showing the chaining of test cases), wherein the output data from the first test scenario comprises output data from one or more test steps of the first subset, and the input data to the second test scenario comprises input data to one or more test steps of the second subset (see Danthuluri paragraph [0062], showing the outputs of the currently executed steps being used as inputs values to the next subsequent steps in a sequence).
As per claim 7, Danthuluri modified with Scholz, Nishide, Guo, Heinecke, Vechev and Chitgupakar teaches wherein the plurality of software service comprises one or more batch services, application program interface (API) services, and user interface services (see Chitgupakar paragraph [0022], showing different service such as user interfaces, APIs and the likes).
As per claim 8, Danthuluri modified with Scholz, Nishide, Guo, Heinecke, Vechev and Chitgupakar teaches wherein said executing the first test scenario comprises an end-to-end test of the software system (see Danthuluri paragraph [0008], showing end-to-end capabilities for executing test cases).
As per claims 11-16, these are the system claims to method claims 3-8 respectively. Therefore, they are rejected for the same reasons as above.
As per claims 19 and 20, these are the computer-readable medium claims to method claims 3 and 5, 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.
Leon et al. (US-PGPUB-NO: 2021/0109848 A1) teaches a test suite comprising a plurality of features and each feature including test scenarios that comprises steps.
Blumenthal et al. (US-PGPUB-NO: 2005/0114839 A1) teaches techniques for test flow control with a test hierarchy.
Arguelles et al. (US-PAT-NO: 8,904,353 B1) teaching of building tests and test frameworks to reduce cost and enable code sharing.
Kastyshyn (US-PGPUB-NO: 2020/0089597 A1) teaching of automated test of web pages.
Rakhmilevich (US-PGPUB-NO: 2019/0065351 A1) teaching of providing a test manager for use with a mainframe rehosting platform.
Palyekar et al. (US-PGPUB-NO: 2018/0217921 A1) teaching of effectively generating and executing test cases for testing.
Simonovic et al. (US-PGPUB-NO: 2020/0320757 A1) teaching processing computational workflows.
Sharma et al. (US-PGPUB-NO: 2019/0065349 A1) teaching automatically executing stateless transactions with data dependency in test cases.
Ashkenazi et al. (US-PAT-NO: 10,261,887 B1) teaches computerized debugging assertions.
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 on (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
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197