DETAILED ACTION
Remarks
Applicant presents a communication filed 23 December 2025 responsive to the 12 November 2025 final Office action (the “Previous Action”).
With the communication, claims 1, 9, 12, 16, 18 and 20 are amended.
Claims 1-20 remain pending. Claims 1, 12 and 18 are the independent claims.
Any unpersuasive arguments are addressed in the “Response to Arguments” section below.
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 .
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers 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 that, in preparing responses, the applicant fully consider the references in their 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.
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.
Response to Arguments
Applicant’s arguments are moot in view of the new ground(s) rejection below, necessitated by Applicant’s amendments.
Allowable Subject Matter
Claims 9, 16 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 10-11 and 17 would be allowable via dependence from claims 9 and 16.
Claim Rejections - 35 USC § 103
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-6, 12-13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Bhandarkar et al. (US 2021/0089435) (art of record – hereinafter Bhandarkar) in view of Ding et al. (US 2022/0350731) (art made of record – hereinafter Ding) in view of Harden et al. (US 2015/0254171) (art of record – hereinafter Harden) in further view of Malamut et al. (US 11,340,968) (art of record – hereinafter Malamut).
As to claim 1, Bhandarkar discloses a system comprising:
a memory storing processor-executable program code of a test automation module; and (e.g., Bhandarkar, par. [0009]: the memory may store instructions that cause the processor to perform one or more of the operations described herein; par. [0024]: running user interface (UI) testing automates)
a processing unit to execute the processor-executable program code to cause the system (e.g., Bhandarkar, par. [0009]: the memory may store instructions that cause the processor to perform one or more of the operations described herein) to:
retrieve an automate for an application under test, (e.g., Bhandarkar, par. [0024]: UI testing automates “(i.e., a script for performing testing of an application)”; par. [0171]: executing each of a plurality of automates [which would necessarily involve retrieving then]) the application under test including a user interface displaying at least one web object; (e.g., Bhandarkar, par. [0024]: running user interface (UI) testing automates; par. [0045]: when the user clicks on button [object] to list all the products then it results in the following sequence of calls; par. [0024]: an HTTP [i.e., web] traffic capturing tool can be used to intercept the http/s calls [so since the objects are used to make web calls, they are web objects])
execute the automate, (e.g., Bhandarkar, par. [0171]: executing each of a plurality of automates) wherein execution of the automate further comprises:
identifying at least one Open Data Protocol (OData) call in the automate; (e.g., Bhandarkar, par. [0003]: monitoring service calls being executed by each of the automates [which must be identified to execute as well]; par. [0005]: the service calls can be according to the open data protocol (ODATA))
at least one test data value for the web object (see immediately below, “top=25” is a data value for the button object)
executing the at least one OData call, wherein execution of the at least one OData call outputs a response (e.g., Bhandarkar, par. [0045]: when the user clicks on button to list all the products then it results in the following sequence of calls: [0046]: the application will call the PRODUCT_SRV ODATA service to retrieved the metadata; par. [0048]: “(This will list all the products. As we have provided top=25 in the call, it will fetch the first 25 records from the database)”).
Bhandarkar does not explicitly disclose the automate including UI-mode executable data and UI-less mode executable data, mapping at least one test data value to a corresponding parameter in the OData call, wherein the mapping is via a mapping logic algorithm that maps sequential dependencies between the plurality of ODAata calls; and executing the at least one OData call with the mapped at least one test data value.
However, in an analogous art, Ding discloses:
the automate including UI-mode executable data and UI-less mode executable data (e.g., Ding, par. [0025]: each step within a scenario [automate] can invoke a service, each of which can be configured to invoke a batch job, an API, or a user interface page, for instance; par. [0031]: first step 410 can function in one of API, batch, or user interface mode. Second step 420 can also function in one of an API, batch or user interface mode; par. [0028]: test input data for the step. Test input data can be data input through a user interface or system generated [the input to each user interface mode step being UI-mode executable data, the input to each API mode step being US-less mode executable data).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the automate of Bhandarkar such that it includes UI-mode executable data and UI-less mode executable data, as taught by Ding, as Ding would provide the advantage of a means of performing test automation of software systems operating in a variety of modes. (See Ding, par. [0011]).
Further, in an analogous art, Harden discloses:
mapping at least one test data value to a corresponding parameter in the call, wherein the is via a mapping logic algorithm; (e.g., Harden, par. [0040]: input parameters and/or outputs of each method. Templates typically assign testing data to the input parameters; Fig. 7 and associated text, par. [0050]: by way of example, the input parameters include first name, last name and age “(e.g., firstNameToFind, lastNameToFind and ageToFind)” for testing the method “(e.g., GET method”. Input pertaining to these input parameters “(e.g., John Smith” with an age of 27)” is provided [see 720 in figure, firstNameToFind is mapped to john, lastNameToFind is mapped to smith, etc.])
executing the at least one call with the mapped at least one test data value (e.g., Harden, par. [0040]: input parameters and/or outputs of each method. Templates typically assign testing data to the input parameters and send a request to that testing data to the method [i.e., call the method with that data]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data values for web objects used to execute OData calls during testing taught by Bhandarkar, such that test data values are mapped to corresponding parameters of the call and the call is executed with the mapped data values, as taught by Harden, as Harden would provide the advantage of a means of performing a test of particular test data values. (See Harden, par. [0040).
Further still, in an analogous art, Malamut discloses:
a mapping logic algorithm that maps sequential dependencies between a plurality of calls (e.g., Malamut, claim 7: a call graph defining a sequence of one or more APIs of the recorded macro; col. 6 ll. 10-16: in this graph each graph vertex represents each function call while each graph edge describes how to map the output data from a parent call to the input data into each subsequent child call. The graph represents a graph of function dependencies of a sequence that is performed by a macro executor; claim 6: each call graph edge describes how to map output data from a parent API call into each subsequent API call; col. 11 ll. 1-18: upon launch, the system determines the API call chain including macro APIs using the call graph. The system then begins macro execution).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the OData calls and mapping logic algorithm of Bhandarkar to include mapping sequential dependencies between a plurality of those calls, as taught by Malamut, as Malamut would provide the advantage of a means of executing a sequence of dependent calls with their appropriate inputs. (See Malamut, col. 6 ll. 10-16).
As to claim 2, Bhandarkar/Ding/Harden/Malamut discloses the system of claim 1 (see rejection of claim 1 above), Bhandarkar further discloses:
wherein the OData call represents a collection of data based on a user interaction (e.g., Bhandarkar, par. [0005]: the service calls can be according to the open data protocol (ODATA); par. [0045]: when the user clicks on button to list all the products then it results in the following sequence of calls: [0046]: the application will call the PRODUCT_SRV ODATA service to retrieved the metadata. [0048]: “(This will list all the products. As we have provided top=25 in the call, it will fetch the first 25 records from the database)”).
As to claim 3, Bhandarkar/Ding/Harden/Malamut discloses the system of claim 1 (see rejection of claim 1 above), but Bhandarkar does not explicitly disclose wherein the response is saved in a temporary storage.
However, in an analogous art, Harden discloses:
wherein the response is saved in a temporary storage (e.g., Harden, Fig. 7 and associated [see figure, the response is stored in the “resp” variable (a variable being temporary storage)]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the execution of OData calls during testing taught by Bhandarkar, such that the response is saved in temporary storage, as taught by Harden, as Harden would provide the advantage of a means of storing the response in a variable and a means of using that variable in later processing. (See Harden, Fig. 7, last 2 lines of element 720).
As to claim 4, Bhandarkar/Ding/Harden/Malamut discloses the system of claim 3 (see rejection of claim 3 above), Bhandarkar further discloses:
wherein at least two OData calls are identified including a first OData call and a second OData call (e.g., Bhandarkar, par. [0003]: monitoring service calls being executed by each of the automates [which must be identified to execute as well]; par. [0005]: the service calls can be according to the open data protocol (ODATA))
As to claim 5, Bhandarkar/Ding/Harden/Malamut discloses the system of claim 4 (see rejection of claim 4 above) and further discloses the first OData call and the second OData call (see rejection of claim 4 above) but does not explicitly disclose wherein execution of the first OData call outputs the response, and the response is transmitted to the second OData call.
However, in an analogous art, Malamut discloses:
wherein execution of the first call outputs the response, and the response is transmitted to the second call (e.g., Malamut, col. 6 ll. 58-60: the system manages the system state at any point between API calls by automatically passing the required outputs of a parent API as inputs to a child API).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the first and second OData calls executed by Bhandarkar, such that the first call outputs a response and the response is transmitted to the second call, as taught by Malamut, as Malamut would provide the advantage of a means of executing a child second call with the appropriate input. (See Malamut, col. 6 ll. 10-16).
As to claim 6, Bhandarkar/Ding/Harden/Malamut discloses the system of claim 4 (see rejection of claim 4 above), Bhandarkar further discloses:
wherein the first OData call and the second OData call are executed sequentially (e.g., Bhandarkar, par. [0024]: running user interface (UI) testing automates; par. [0045]: when the user clicks on button [object] to list all the products then it results in the following sequence of calls; par. [0046]: 1. the application will call the PRODUCT_SRV ODATA service; par. [0047]: 2. PRODUCT_SRV service will have a GET request; par. [0049]. 3. Another call might by to fetch the product category).
As to claim 12, Bhandarkar discloses a method comprising:
retrieving an automate for an application under test, (e.g., Bhandarkar, par. [0024]: UI testing automates “(i.e., a script for performing testing of an application)”; par. [0171]: executing each of a plurality of automates [which would necessarily involve retrieving then]) the application under test including a user interface displaying at least one web object; (e.g., Bhandarkar, par. [0024]: running user interface (UI) testing automates; par. [0045]: when the user clicks on button [object] to list all the products then it results in the following sequence of calls; par. [0024]: an HTTP [i.e., web] traffic capturing tool can be used to intercept the http/s calls [so since the objects are used to make web calls, they are web objects])
executing the automate (e.g., Bhandarkar, par. [0171]: executing each of a plurality of automates) comprising:
(i) identifying a first Open Data Protocol (OData) call in the automate, (e.g., Bhandarkar, par. [0003]: monitoring service calls being executed by each of the automates [which must be identified to execute as well]; par. [0005]: the service calls can be according to the open data protocol (ODATA)) wherein the automate includes a plurality of OData calls and the OData calls represent a collection of data based on a user interaction with a user interface; (e.g., Bhandarkar, par. [0045]: when the user clicks on button to list all the products then it results in the following sequence of calls: [0046]: the application will call the PRODUCT_SRV ODATA service to retrieved the metadata. [0048]: “(This will list all the products. As we have provided top=25 in the call, it will fetch the first 25 records from the database)”)
at least one test data value for the web object (see immediately below, “top=25” is a data value for the button object)
(iii) executing the at least one OData call, wherein execution of the at least one OData call outputs a response (e.g., Bhandarkar, par. [0045]: when the user clicks on button to list all the products then it results in the following sequence of calls: [0046]: the application will call the PRODUCT_SRV ODATA service to retrieved the metadata; par. [0048]: “(This will list all the products. As we have provided top=25 in the call, it will fetch the first 25 records from the database)”).
Bhandarkar does not explicitly disclose: the automate including UI-mode executable data and UI-less mode executable data; (ii) mapping at least one test data value to a corresponding parameter in the OData call, where the mapping is via a mapping logic algorutm that maps sequential dependencies between a plurality of OData calls; and (iii) executing the at least one OData call with the mapped at least one test data value.
However, in an analogous art, Ding discloses:
the automate including UI-mode executable data and UI-less mode executable data; (e.g., Ding, par. [0025]: each step within a scenario [automate] can invoke a service, each of which can be configured to invoke a batch job, an API, or a user interface page, for instance; par. [0031]: first step 410 can function in one of API, batch, or user interface mode. Second step 420 can also function in one of an API, batch or user interface mode; par. [0028]: test input data for the step. Test input data can be data input through a user interface or system generated [the input to each user interface mode step being UI-mode executable data, the input to each API mode step being US-less mode executable data).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the automate of Bhandarkar such that it includes UI-mode executable data and UI-less mode executable data, as taught by Ding, as Ding would provide the advantage of a means of performing test automation of software systems operating in a variety of modes. (See Ding, par. [0011]).
Further, in an analogous art, Harden discloses:
(ii) mapping at least one test data value to a corresponding parameter in the call, wherein the mapping is via a mapping logic algorithm; (e.g., Harden, par. [0040]: input parameters and/or outputs of each method. Templates typically assign testing data to the input parameters; Fig. 7 and associated text, par. [0050]: by way of example, the input parameters include first nam, last name and age “(e.g., firstNameToFind, lastNameToFind and ageToFind)” for testing the method “(e.g., GET method”. Input pertaining to these input parameters “(e.g., John Smith” with an age of 27)” is provided [see 720 in figure, firstNameToFind is mapped to john, lastNameToFind is mapped to smith, etc.]) and
(iii) executing the at least one call with the mapped at least one test data value (e.g., Harden, par. [0040]: input parameters and/or outputs of each method. Templates typically assign testing data to the input parameters and send a request to that testing data to the method [i.e., call the method with that data]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data values for web objects used to execute OData calls during testing taught by Bhandarkar, such that test data values are mapped to corresponding parameters of the call and the call is executed with the mapped data values, as taught by Harden, as Harden would provide the advantage of a means of performing a test of particular test data values. (See Harden, par. [0040).
Further still, in an analogous art, Malamut discloses:
a mapping logic algorithm that maps sequential dependencies between a plurality of calls (e.g., Malamut, claim 7: a call graph defining a sequence of one or more APIs of the recorded macro; col. 6 ll. 10-16: in this graph each graph vertex represents each function call while each graph edge describes how to map the output data from a parent call to the input data into each subsequent child call. The graph represents a graph of function dependencies of a sequence that is performed by a macro executor; claim 6: each call graph edge describes how to map output data from a parent API call into each subsequent API call; col. 11 ll. 1-18: upon launch, the system determines the API call chain including macro APIs using the call graph. The system then begins macro execution).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the OData calls and mapping logic algorithm of Bhandarkar to include mapping sequential dependencies between a plurality of those calls, as taught by Malamut, as Malamut would provide the advantage of a means of executing a sequence of dependent calls with their appropriate inputs. (See Malamut, col. 6 ll. 10-16).
As to claim 13, it is a method claim having limitations substantially the same as those of claim 5. Accordingly, it is rejected for substantially the same reasons.
As to claim 18, it is a medium claim having limitations substantially the same as those of claim 12. Accordingly, it is rejected for substantially the same reasons. Further limitations, disclosed by Bhandarkar, include:
a non-transitory, computer readable medium having executable instructions stored therein to perform a method, (e.g., Bhandarkar, par. [0009]: the memory may store instructions that cause the processor to perform one or more of the operations described herein) the method comprising (see rejection of claim 12 above).
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Bhandarkar (US 2021/0089435) in view of Ding (US 2022/0350731) in view of Harden (US 2015/0254171) in view of Malamut et al. (US 11,340,968) in further view of Arguelles et al. (US 10,452,522) (art of record – hereinafter Arguelles).
As to claim 7, Bhandarkar/Ding/Harden/Malamut discloses the system of claim 5 (see rejection of claim 5 above), and further discloses the first OData call and the second OData call (see rejection of claim 4 above) but does Bhandarkar/Ding/Harden/Malamut does not explicitly disclose wherein receipt of the response of the first OData call received by automation tool initiates execution of the second OData call.
However, in an analogous art, Arguelles discloses:
wherein receipt of the response of the first call received by automation tool initiates execution of the second call (e.g., Arguelles, col. 8 ll. 38-48: a first API call generates a response message. Data in the response message is then passed as an input parameter to a second API call. In such a case, the test platform [automation tool] could invoke the second API call using data from the response message [Since the platform uses the response, it receives it]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the first and second OData calls executed by Bhandarkar, such that the first call outputs a response and the response is transmitted to the second call and receipt of the response of the first call received by automation tool initiates execution of the second call, as taught by Arguelles, as Arguelles would provide the advantage of a means of executing a sequence of dependent calls, as suggested by Malamut. (See Malamut, col. 6 ll. 14-16, Arguelles, col. 8 ll. 38-48).
As to claim 14, it is a method claim having limitations substantially the same as those of claim 7. Accordingly, it is rejected for substantially the same reasons.
Claims 8, 15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bhandarkar (US 2021/0089435) in view of Ding (US 2022/0350731) in view of Harden (US 2015/0254171) in view of Malamut (US 11,340,968) in further view of Surace et al. (US 10,552,299) (art of record – hereinafter Surace).
As to claim 8, Bhandarkar/Ding/Harden/Malamut discloses the system of claim 1 (see rejection of claim 8 above), but does not explicitly disclose further comprising processor-executable program code to cause the system to: generate the automate by recording one or more user actions for the application under test.
However, in an analogous art, Surace discloses further comprising processor-executable program code to cause the system to:
generate the automate by recording one or more user actions for the application under test (e.g., Surace, col. 39 ll. 59-67: automatically generating one or more test scripts [automates] from one or more user logs 602. User logs 602 may record data associate with a user using web application 630 “(also called an application under test in FIG. 16)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the automate of Bhandarkar, such that it is generated by recording one or more user actions for the application under test, taught by Surace, as Surace would provide the advantage of a means of generating automates that resemble the paths typically performed by a user. (See Surace, col. 2 ll. 45-50).
As to claim 15, it is a method claim having limitations substantially the same as those of claim 7. Accordingly, it is rejected for substantially the same reasons.
As to claim 19, it is a medium claim having limitations substantially the same as those of claim 8. Accordingly, it is rejected for substantially the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM 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, 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.
/TODD AGUILERA/Primary Examiner, Art Unit 2192