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.
Response to Arguments
Applicant’s arguments filed 05/11/2026 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, Vechev et al. (US-PGPUB-NO: 2012/0179650 A1) hereinafter Vechev and Chitgupakar et al. (US-PGPUB-NO: 2021/0318857 A1) hereinafter Chitgupakar.
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 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 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 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”.
Danthuluri modified with Scholz, Nishide, Guo, Heincke and Vechev do not explicitly teach the output data of the first test step is a first JavaScript Object Notation (json) object that includes a parent object comprising one or more child objects, wherein the second test step further receives as input data a second json object, wherein the second step includes a parent object comprising one or more child objects; passing json objects that include key values, between the first test scenario and second test scenario, wherein key values within the json objects define paths during configuration phase of testing. However, Chitgupakar teaches the output data of the first test step is a first JavaScript Object Notation (json) object that includes a parent object comprising one or more child objects, wherein the second test step further receives as input data a second json object, wherein the second step includes a parent object comprising one or more child objects (see Chitgupakar paragraph [0060], “Further, the parent child template is configured to process a user query as a parent query to generate one or more child queries and utilize the one or more child queries to render output from the parent query. It may be understood that child query output will be added back with a new key in the output data. Generally, OutputMap of a parent query is in JSON string format. If OutputMap has a list with a single element, it returns a JSON string. If OutputMap has a list with more than a single element, it returns a JSON Array string. Further, merged parent-child query output is a JSON exposed as Rest API. In the present examples, a parent child query is formed using the following terms: (i) query_template_group for template group path of parent query; (ii) query_template_name for parent query template name; (iii) query_inputs for input to the parent child queries in which input data can be converted to map using asMap (eg: $data,aMap$) or a string using asString (eg: $data.asString$); (iv) child for child queries to be rendered as a list of maps. Herein, a child query has the following parameters: a) query_template_group: Template group path of child query; b) query_template_name: Child query template name; c) relation key: Relation key between the parent and child query (i.e., columns in parent query to reuse in the child queries); and d) query_output_key: child query output added as a key in output JSON”); passing json objects that include key values, between the first test scenario and second test scenario, wherein key values within the json objects define paths during configuration phase of testing (see Chitgupakara paragraph [0062], “Furthermore, herein, the sequential template is configured to pass on the output of a user query, to be utilized by a successive user query as an input. That is, queries in the sequential pattern can pick the output from other queries in the sequence. Herein, each query output will be added to a Data Map (i.e., a map with keys where the keys store the query outputs) with the key provided in input. A sequential query is formed using the following terms: (i) input_data which is input to the parent child queries and in which input data initially is in JSONString but can be converted to map using asMap (eg: $data.asMap$) or a string using asString (eg: $data.asString$); (ii) query_template_group which is template group path of parent query; (iii) query_template_name which is parent query template name; and (iv) query_output_key in which child query output added as a key in output JSON and (v) query_type which may be: (a) select in which query from template is rendered to an OutMap; (b) insert, update, delete in which query from template is rendered and updated in the backend database; (c) html, string in which query from template is rendered as is and presented in template; (d) data, JSON in which output from rendered template is in the form of a JSON; (e) JSONmapper, again, in which output from rendered template is in the form of a JSON; and (f) Encoded_string in which output from rendered template is in the form of an encoded string”).
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 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 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 9-16, these are the system claims to method claims 1-8, respectively. Therefore, they are rejected for the same reasons as above.
As per claims 17-20, these are the computer-readable medium claims to method claims 1-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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
/GREGORY A KESSLER/Primary Examiner, Art Unit 2197
Prosecution Insights