DETAILED ACTION
This action is responsive to Remarks and Claim amendments filed on March 02, 2026.
Claims 1-18 have been amended.
Claims 1-20 are pending and are presented to examination.
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.
Response to amendments
The objection of claims 1-20 is withdrawn in view of applicant’s amendments.
The rejection of claims 1-20 under 35 U.S.C. 101 (Abstract Idea) is withdrawn in view of applicant’s amendments.
Response to Arguments
Rejections under 35 U.S.C. 103 Applicant has argued that Arkadyev and Chilupuri, along with the remaining arts of record, do not teach the newly added limitations of independent claims 1, 11 and 18 (Remarks, pages 12-16). Applicant's arguments have been fully considered and are persuasive. Therefore, the rejection is withdrawn. However, upon further consideration, a new ground of rejection is made as set forth in details below. See Dheeraj Kumar Aggarwal (“Boost your API Test efficiency using swagger and excel sheets), CacheControl (“Hippie-Swagger”), Zhenyu Liu et al. (“A Maintainability Spreadsheet-Driven Regression Test Automation Framework”), Hassan Khawaja ("Automated API Testing using Postman and Excel”), Hruska et al. (US Pat. No. 9,612,940) and Wybouw-Cognard (US Pub. No. 2002/0116153), arts being made of record as applied herein.
Claim Objections
Claims 4, 9 and 15-16 are objected to because of the following informalities: Claim 4 recites the limitation “defining a workbook of the testing spreadsheet as a group of test cases that include the first test case and the second test case.” in lines 5-6. Claim 9 recites the limitation “evaluating the testing spreadsheet to determine that a prefix character is assigned to at least one of a value within a cell of the testing spreadsheet to comment or exclude the value from the call, a method parameter to comment or exclude the method parameter from the call, or a sheet name to exclude or comment a corresponding test case script;” in lines 2-6.
Claim 15 recites “perform test execution for the second thread by transmitting [[a]] the framed API request with the API payload to the API endpoint identified by the API path, receiving an API response, and checking the API response for the expected status code and values.”.
Appropriate correction is required. Please amend the claim language as indicated in bold.
Dependent claim 16 do not overcome the deficiency of the base claim and, therefore, are objected for the same reasons as the base claim.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-4, 6, 8, 11-12 and 14-19 are rejected under 35 U.S.C. 103 as being unpatentable over Dheeraj Kumar Aggarwal (“Boost your API Test efficiency using swagger and excel sheets”, hereinafter Aggarwal) in view of CacheControl (“Hippie-Swagger”, hereinafter CacheControl) in view of Zhenyu Liu et al. (“A Maintainability Spreadsheet-Driven Regression Test Automation Framework”, hereinafter Liu) and further in view of Hassan Khawaja ("Automated API Testing using Postman and Excel”, hereinafter Khawaja).
With respect to claim 1 (currently amended), Aggarwal teaches a method, comprising:
parsing and converting a testing spreadsheet from a spreadsheet format to a script format as a test case script based upon test data [[and control values]] parsed from rows of the testing spreadsheet, wherein the testing spreadsheet is converted into the test case script for executing a test within a computing environment [[according to the control values used to control an execution flow]] for executing the test case script using the test data (Aggarwal discloses parsing a testing spreadsheet populated with test data from rows into automated test logic that executes within a computing environment. Aggarwal, Section "4. Write Test Data" ("We should have a separate excel sheet for each API available in our swagger file. And in excel sheet, we can write the test data to validate the different conditions of the API"); Section "Benefits: 3. Easier to Maintain" ("Checking conditions of an API is like adding a new row in the excel sheet with desired data"); Section "Benefits: 4. Separation of concerns" ("this process separates the test data from the automation logic"); Section "Benefits: 2. Increased Test efficiency" ("swagger file becomes the single source of truth for all of the generated test logic"). The row-based parsing of the testing spreadsheet into the test case script reads on the recited "parsing and converting a testing spreadsheet . . . as a test case script based upon test data parsed from rows of the testing spreadsheet" and the recited execution within the computing environment using the test data.)
executing an application programming interface (API) [[verification process upon]] API calls of threads defined within the test case script [[to compare a first API call of a first thread to]] a resource listing file of available APIs associated with resources of the computing environment (Aggarwal discloses that the test case script is composed of API calls directed at the application under test and that the swagger file is the resource listing file of available APIs of the computing environment. Aggarwal, Section "1. Write API Specification" ("The process starts with documenting your API specifications in swagger files"); Section "Process" (executing API calls against the application under test); Section "Benefits: 2. Increased Test efficiency" ("swagger file becomes the single source of truth for all of the generated test logic"). The swagger-driven API calls of the test script read on the recited "API calls of threads defined within the test case script" and the swagger file reads on the recited "resource listing file of available APIs associated with resources of the computing environment."). executing the test case script to perform the execution flow that executes a second thread of a second API call [[that passed the API verification process]] [[and skips execution of the first thread]], wherein [[the control values are used to execute the second thread by framing the second API call as a framed API request]] transmitted to an API endpoint, defined by the resource listing file, for performing an operational step of the test upon a resource of the computing environment (Aggarwal discloses execution of the test case script wherein API calls are transmitted to API endpoints defined by the swagger file to perform operational steps of the test upon resources of the computing environment. Aggarwal, Section "Process" (executing the generated test against the application under test); Section "Benefits: 2. Increased Test efficiency" (the swagger file as the source of API endpoint information used by the test logic). The execution of the API test against swagger-defined endpoints reads on the recited "executing the test case script to perform the execution flow that executes a second thread of a second API call . . . transmitted to an API endpoint, defined by the resource listing file, for performing an operational step of the test upon a resource of the computing environment."). Aggarwal is silent to disclose, however in an analogous art, CacheControl teaches: verification process upon (CacheControl discloses a tool, hippie-swagger, that executes a verification process upon each API call as the test suite runs. CacheControl, README "Synopsis" ("hippie-swagger is a tool for testing RESTful APIs. In addition to validating api behavior, it will fail tests when swagger documentation is missing or inaccurate. As the test suite runs, any request or response details not matching the swagger file will throw an appropriate exception, failing the spec"); README "Validations" ("When hippie-swagger detects it is interacting with the app in ways not specified in the swagger file, it will throw an error and fail the test"). The per-call verification operation reads on the recited "verification process upon" API calls.). to compare a first API call of a first thread to (CacheControl discloses comparison of each API call (its path, method, parameters, and body) against the swagger file. CacheControl, README "Usage" ("When specifying a url(.get, .post, .patch, .url, etc), use the swagger path"); README "Validations: Paths" (comparison against swagger-defined paths); README "Validations: Method validation" (comparison against swagger-defined methods); README "Validations: Parameter format" (comparison against swagger-defined parameter formats). The per-call comparison against the swagger reads on the recited "to compare a first API call of a first thread to" the resource listing file.). in response to detecting a mismatch between the first API call and the resource listing file, generating an error report for the first thread [[and continuing the execution flow for threads with API calls that passed the API verification process]] (CacheControl discloses generating a specific error report identifying the mismatch upon detecting that an API call does not match the swagger file. CacheControl, README "Validations" ("it will throw an error and fail the test"); README "Validations: Paths" ("Swagger spec does not define path: pathNotMentionedInSwagger"); README "Validations: Method validation" ("Swagger spec does not define method: ‘post’ in path /users"); README "Validations: Parameter format" ("Invalid format for parameter {userId}"); README "Validations: Required Parameters" ("Missing required parameter in path: username"). The per-call error reports identifying the specific mismatch read on the recited "in response to detecting a mismatch between the first API call and the resource listing file, generating an error report for the first thread."). that passed the API verification process (CacheControl discloses that API calls that pass the verification proceed to transmission while those that fail throw an exception. CacheControl, README "Synopsis" ("any request or response details not matching the swagger file will throw an appropriate exception, failing the spec"); README "Basic Usage" (chained .get/.pathParams/.expectStatus/.end calls by which verified calls proceed). The transmission of verified-passing API calls reads on the recited "that passed the API verification process."). 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 spreadsheet-driven API testing framework of Aggarwal to incorporate CacheControl’s per-call API verification process and mismatch-error reporting. The motivation arises because Aggarwal expressly relies on the swagger file as "the single source of truth" for the test logic (Aggarwal, Section "Benefits: 2. Increased Test efficiency"), and CacheControl expressly states its purpose is to "fail tests when swagger documentation is missing or inaccurate" (CacheControl, README "Synopsis"), providing a known mechanism for enforcing synchronization between test calls and the swagger specification. The combination is no more than the use of a known technique to improve a similar method in the same way, yielding the predictable result of a spreadsheet-driven API testing framework that verifies each API call defined by a thread of the test case script against the swagger file before transmission.
Aggarwal in view of CacheControl is silent to disclose, however in an analogous art, Liu teaches: and control values (Liu discloses control values populated within rows of a control spreadsheet alongside test data and form spreadsheets. Liu et al., Section III.B "SpreadSheet Definition," page 1183 ("The form, data and control spreadsheet should be defined by test developer"); Table I and Section III.B.1 "Control," page 1183 (Control Spreadsheet rows populated with control values Tag, Failure, LogFile, and NextFlow). The control values populated in spreadsheet rows alongside test data read on the recited "and control values" parsed from rows of the testing spreadsheet.). according to the control values used to control an execution flow (Liu discloses that the per-row control values direct the test execution flow. Liu et al., Section III.A "Script," page 1182 ("For the different conditions of test case, we design an execution flag. The framework will select the correct execution branch of test script according to condition"; "the symbol Tag is necessary control to select the appropriate branch of test case"); Table I, page 1183 (Tag = Execution Flag; NextFlow = Next Control Spreadsheet). The control values directing the framework’s selection of test branches read on the recited "according to the control values used to control an execution flow."). and continuing the execution flow for threads with API calls that passed the API verification process (Liu discloses that the framework processes per-row failures and proceeds to the next branch of the execution flow rather than terminating overall test execution. Liu et al., Table I, page 1183 ("Failure" field = "Failure Exception Procession"; "NextFlow" field = "Next Control Spreadsheet"); Section III.A, page 1182 ("The framework will select the correct execution branch of test script according to condition"). The framework-level continuation through alternative branches after a per-row failure reads on the recited "and continuing the execution flow for threads with API calls that passed the API verification process."). and skips execution of the first thread (Liu discloses that the Tag (Execution Flag) control value selectively skips a particular branch. Liu et al., Section III.A, page 1182 ("the symbol Tag is necessary control to select the appropriate branch of test case"); Table I, page 1183 (Tag = Execution Flag). The selective skipping of a branch based on Tag reads on the recited "and skips execution of the first thread."). the control values are used to execute the second thread by (Liu discloses that the control values of the control spreadsheet drive which branches of the test execution are executed. Liu et al., Section III.A, page 1182 (framework selects the execution branch based on Tag); Section III.B.1, page 1183 (Control Spreadsheet values Tag, Failure, NextFlow, LogFile direct framework behavior on a per-row basis). The use of per-row control values to determine which branch executes reads on the recited "the control values are used to execute the second thread by."). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Aggarwal in view of CacheControl to incorporate Liu’s control-spreadsheet structure, in which per-row control values direct the execution flow and continue execution after a per-row failure. The motivation arises because CacheControl provides per-call mismatch detection but is silent on the framework-level response to a per-call failure, and Liu et al. provides the framework-level continuation mechanism by which a single failure does not halt the broader execution flow (Liu, Abstract, page 1181, identifying this as making the framework "easy to maintain"). The combination is the use of a known technique to improve a similar method in the same way, yielding the predictable result of a spreadsheet-driven API testing framework in which per-row control values direct the execution flow and execution continues for verified threads while the failed thread is skipped. Aggarwal in view of CacheControl and Liu is silent to disclose, however in an analogous art, Khawaja teaches: framing the second API call as a framed API request (Khawaja discloses framing each API call as a framed request whose JSON payload is composed from key/value pairs corresponding to cells of the testing spreadsheet. Khawaja, Section "Step 3" ("Next I will replace the string value to the name of the headers of my CSV file where the test values will picked from as demonstrated below to point to variables that will be header in my CSV file"); Section "Step 3," illustrated "Variables Name as Header of the CSV File" (JSON body "email": "{{email}}", "password": "{{password}}"); Section "Step 3" ("the email and password header will be consider as the variable to pick out the values from those column to mapped to the variable in our JSON Body that we previously configured"); Section "Step 5: Import the CSV File into Postman & Run the Test Cases". The composition of the API request from key/value cells of the testing spreadsheet reads on the recited "framing the second API call as a framed API request."). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Aggarwal in view of CacheControl and Liu to incorporate Khawaja’s mechanism of framing API requests from key/value cells of the testing spreadsheet. The motivation arises because Aggarwal expressly teaches that the test data residing in cells of the testing spreadsheet should be used to populate the API request body for each test condition (Aggarwal, Section "4. Write Test Data"), and Khawaja provides a concrete, known mechanism for accomplishing precisely that: a variable-substitution syntax mapping cells of the testing spreadsheet to fields within the JSON payload of the API request. The combination is the use of a known technique to improve a similar method in the same way, yielding the predictable result of a test framework in which each API call is framed from cell values of the testing spreadsheet.
With respect to claim 3 (currently amended), Aggarwal teaches comparing the framed API request with the resource listing file to select an API with the API endpoint as a destination for transmission of the framed API request (Aggarwal discloses that the swagger file (resource listing file) provides the API endpoint to which the framed API request is directed. Aggarwal, Section "Benefits: 2. Increased Test efficiency" ("swagger file becomes the single source of truth for all of the generated test logic"); Section "1. Write API Specification." CacheControl further teaches the active comparison of the framed API request against the swagger to select the destination endpoint: README "Usage" ("When specifying a url(.get, .post, .patch, .url, etc), use the swagger path"); README "Validations: Paths". The selection of the API endpoint by comparing the framed request to the swagger file reads on the recited "comparing the framed API request with the resource listing file to select an API with the API endpoint as a destination for transmission of the framed API request."). Aggarwal in view of CacheControl in view of Liu is silent to disclose, however in an analogous art, Khawaja teaches framing an API request, of the second API call, with a payload and key/value pair within a cell of the testing spreadsheet to create the framed API request (Khawaja discloses framing the API request with a JSON payload populated from key/value pairs within cells of the testing spreadsheet via the {{variable}} prefix syntax. Khawaja, Section "Step 3," illustrated "Variables Name as Header of the CSV File" (JSON body "email": "{{email}}", "password": "{{password}}"); Section "Step 3" ("the email and password header will be consider as the variable to pick out the values from those column to mapped to the variable in our JSON Body"). The composition of the JSON payload from key/value pairs in cells of the testing spreadsheet reads on the recited "framing an API request . . . with a payload and key/value pair within a cell of the testing spreadsheet to create the framed API request.").
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Aggarwal in view of CacheControl and Liu to incorporate Khawaja’s mechanism of framing API requests from key/value cells of the testing spreadsheet. The motivation arises because Aggarwal expressly teaches that the test data residing in cells of the testing spreadsheet should be used to populate the API request body for each test condition (Aggarwal, Section "4. Write Test Data"), and Khawaja provides a concrete, known mechanism for accomplishing precisely that: a variable-substitution syntax mapping cells of the testing spreadsheet to fields within the JSON payload of the API request. The combination is the use of a known technique to improve a similar method in the same way, yielding the predictable result of a test framework in which each API call is framed from cell values of the testing spreadsheet. With respect to claim 4 (currently amended), Aggarwal teaches defining a first test case as a first sheet within the testing spreadsheet; defining a second test case as a second sheet within the testing spreadsheet; and defining a workbook of the spreadsheet as a group of test cases that include the first test case and the second test case (Aggarwal discloses organizing the testing spreadsheet with one separate Excel sheet per API to be tested, the collection forming a workbook of test cases. Aggarwal, Section "4. Write Test Data" ("We should have a separate excel sheet for each API available in our swagger file. And in excel sheet, we can write the test data to validate the different conditions of the API"). The per-API separate sheets within the same Excel workbook read on the recited "defining a first test case as a first sheet within the testing spreadsheet; defining a second test case as a second sheet within the testing spreadsheet; and defining a workbook of the spreadsheet as a group of test cases."). With respect to claim 6 (currently amended), Aggarwal in view of CacheControl in view of Khawaja is silent to disclose, however in an analogous art, Liu teaches performing the test to generate at least one of console logs, test logs in an HTML format, or debug logs in the HTML format (Liu discloses generation of test logs during test execution via a spreadsheet-driven control value. Liu, Table I and Section III.B.1 "Control," page 1183 ("LogFile" field defined as "Test Log File Name"). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Aggarwal in view of CacheControl to incorporate Liu’s control-spreadsheet structure, in which per-row control values direct the execution flow and continue execution after a per-row failure. The motivation arises because CacheControl provides per-call mismatch detection but is silent on the framework-level response to a per-call failure, and Liu et al. provides the framework-level continuation mechanism by which a single failure does not halt the broader execution flow (Liu, Abstract, page 1181, identifying this as making the framework "easy to maintain"). The combination is the use of a known technique to improve a similar method in the same way, yielding the predictable result of a spreadsheet-driven API testing framework in which per-row control values direct the execution flow and execution continues for verified threads while the failed thread is skipped. With respect to claim 8 (Currently Amended), Aggarwal in view of CacheControl in view of Liu is silent to disclose, however in an analogous art, Khawaja teaches declaring and accessing a variable by assigning a prefix character to a variable name within the testing spreadsheet (Khawaja discloses a syntax for declaring and accessing variables within the testing spreadsheet in which a prefix character is assigned to the variable name. Khawaja, Section "Step 3," illustrated "Variables Name as Header of the CSV File" (variables written as "{{email}}" and "{{password}}"); Section "Step 3" ("the email and password header will be consider as the variable to pick out the values from those column to mapped to the variable in our JSON Body that we previously configured"). The opening brace prefix-character syntax used both to declare and to resolve the variable to its corresponding cell value reads on the recited "declaring and accessing a variable by assigning a prefix character to a variable name within the testing spreadsheet.").
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Aggarwal in view of CacheControl and Liu to incorporate Khawaja’s mechanism of framing API requests from key/value cells of the testing spreadsheet. The motivation arises because Aggarwal expressly teaches that the test data residing in cells of the testing spreadsheet should be used to populate the API request body for each test condition (Aggarwal, Section "4. Write Test Data"), and Khawaja provides a concrete, known mechanism for accomplishing precisely that: a variable-substitution syntax mapping cells of the testing spreadsheet to fields within the JSON payload of the API request. The combination is the use of a known technique to improve a similar method in the same way, yielding the predictable result of a test framework in which each API call is framed from cell values of the testing spreadsheet.
With respect to claim 11, the claim is directed to a computing device that corresponds to the method recited in claim 1, respectively (see the rejection of claim 1 above). The additional structural elements of claim 11 (a memory comprising machine executable code, and a processor coupled to the memory) are inherent in each of the cited references and are otherwise within the level of ordinary skill in the art, as further detailed in the rejection of claim 1 above. With respect to claim 12 (currently amended), Aggarwal in view of CacheControl in view of Khawaja is silent to disclose, however in an analogous art, Liu teaches generate, during execution of the test, [[console logs describing steps and threads that were executed,]] skipped steps and skipped threads that were not executed, [[and test results]] (Liu discloses the framework’s generation of test logs during execution and per-row control of which branches are skipped versus executed. Liu et al., Table I and Section III.B.1, page 1183 ("LogFile" field = "Test Log File Name"); Section III.A, page 1182 (Tag/Execution Flag controls which branch is executed and which is skipped); Section III.B.1, page 1183 (Failure = Failure Exception Procession; NextFlow = Next Control Spreadsheet). The framework’s record of which per-row branches were executed and which were skipped reads on the recited "skipped steps and skipped threads that were not executed.").
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Aggarwal in view of CacheControl to incorporate Liu’s control-spreadsheet structure, in which per-row control values direct the execution flow and continue execution after a per-row failure. The motivation arises because CacheControl provides per-call mismatch detection but is silent on the framework-level response to a per-call failure, and Liu et al. provides the framework-level continuation mechanism by which a single failure does not halt the broader execution flow (Liu, Abstract, page 1181, identifying this as making the framework "easy to maintain"). The combination is the use of a known technique to improve a similar method in the same way, yielding the predictable result of a spreadsheet-driven API testing framework in which per-row control values direct the execution flow and execution continues for verified threads while the failed thread is skipped.
Aggarwal in view of Liu in view of Khawaja is silent to disclose, however in an analogous art, CacheControl teaches console logs describing steps and threads that were executed (CacheControl discloses that, as the test suite runs, console-level output is emitted describing the executed API calls and any swagger-mismatch failures. CacheControl, README "Validations" ("As the test suite runs, any request or response details not matching the swagger file will throw an appropriate exception, failing the spec"); examples in README "Validations: Paths," "Method validation," "Parameter format," and "Required Parameters." The per-call console output describing executed test calls reads on the recited "console logs describing steps and threads that were executed.") and test results (CacheControl discloses that the framework emits per-call test results identifying passing and failing calls. CacheControl, README "Synopsis" (failed calls throw exceptions failing the spec); README "Basic Usage" (chained .expectStatus and .expectValue calls determining per-call pass/fail). The per-call pass/fail test result output reads on the recited "and test results.").
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 spreadsheet-driven API testing framework of Aggarwal to incorporate CacheControl’s per-call API verification process and mismatch-error reporting. The motivation arises because Aggarwal expressly relies on the swagger file as "the single source of truth" for the test logic (Aggarwal, Section "Benefits: 2. Increased Test efficiency"), and CacheControl expressly states its purpose is to "fail tests when swagger documentation is missing or inaccurate" (CacheControl, README "Synopsis"), providing a known mechanism for enforcing synchronization between test calls and the swagger specification. The combination is no more than the use of a known technique to improve a similar method in the same way, yielding the predictable result of a spreadsheet-driven API testing framework that verifies each API call defined by a thread of the test case script against the swagger file before transmission.
With respect to claim 14 (Currently Amended), Aggarwal in view of CacheControl in view of Liu is silent to disclose, however in an analogous art, Khawaja teaches form a test case that includes the second thread, wherein the second API call of the second thread is framed as the framed API request to include an API path in a key/value pair, an API payload, [[and an expected status code and values expected from a response]] (Khawaja discloses framing the API request configured in Postman to include the API path and JSON payload built from key/value cells of the testing spreadsheet. Khawaja, Section "Step 3" (configuring the API path (e.g., https://reqres.in/api/register) and the JSON body populated with "{{variable}}" references mapped to columns of the testing spreadsheet); Section "Step 2," "Sample Test Case Spreadsheet" (columns for "Expected Response Code" and "Expected Response Body"). The API path and JSON-body framing read on the recited "API path in a key/value pair" and "API payload.").
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Aggarwal in view of CacheControl and Liu to incorporate Khawaja’s mechanism of framing API requests from key/value cells of the testing spreadsheet. The motivation arises because Aggarwal expressly teaches that the test data residing in cells of the testing spreadsheet should be used to populate the API request body for each test condition (Aggarwal, Section "4. Write Test Data"), and Khawaja provides a concrete, known mechanism for accomplishing precisely that: a variable-substitution syntax mapping cells of the testing spreadsheet to fields within the JSON payload of the API request. The combination is the use of a known technique to improve a similar method in the same way, yielding the predictable result of a test framework in which each API call is framed from cell values of the testing spreadsheet.
Aggarwal in view of Liu in view of Khawaja is silent to disclose, however in an analogous art, CacheControl teaches and an expected status code and values expected from a response (CacheControl discloses inclusion of expected status codes and expected values within the framed API request configuration via chained .expectStatus and .expectValue methods. CacheControl, README "Basic Usage" ("hippie(app, swagger).get('/users/{username}').pathParams({username: 'cachecontrol'}).expectStatus(200).expectValue('user.first', 'John').expectHeader('cache-control', 'no-cache').end(function(err, res, body){...})"). The configured .expectStatus and .expectValue checks within the framed request read on the recited "and an expected status code and values expected from a response.").
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 spreadsheet-driven API testing framework of Aggarwal to incorporate CacheControl’s per-call API verification process and mismatch-error reporting. The motivation arises because Aggarwal expressly relies on the swagger file as "the single source of truth" for the test logic (Aggarwal, Section "Benefits: 2. Increased Test efficiency"), and CacheControl expressly states its purpose is to "fail tests when swagger documentation is missing or inaccurate" (CacheControl, README "Synopsis"), providing a known mechanism for enforcing synchronization between test calls and the swagger specification. The combination is no more than the use of a known technique to improve a similar method in the same way, yielding the predictable result of a spreadsheet-driven API testing framework that verifies each API call defined by a thread of the test case script against the swagger file before transmission. With respect to claim 15 (currently amended), Aggarwal in view of Liu in view of Khawaja is silent to disclose, however in an analogous art, CacheControl teaches perform test execution for the second thread by transmitting a framed API request with the API payload to the API endpoint identified by the API path, receiving an API response, and checking the API response for the expected status code and values (CacheControl discloses an end-to-end test execution flow in which the framed API request is transmitted to the swagger-defined endpoint, the response is received via the test callback, and the response is checked for an expected status and values. CacheControl, README "Basic Usage" ("hippie(app, swagger).get('/users/{username}').pathParams({username: 'cachecontrol'}).expectStatus(200).expectValue('user.first', 'John').expectHeader('cache-control', 'no-cache').end(function(err, res, body) { if (err) throw err; });"); README "Validations: Response format". The .get/.pathParams chain transmits the request, the .end callback receives the response, and .expectStatus/.expectValue check the response — reading on the recited "transmitting a framed API request . . . receiving an API response, and checking the API response for the expected status code and values.").
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 spreadsheet-driven API testing framework of Aggarwal to incorporate CacheControl’s per-call API verification process and mismatch-error reporting. The motivation arises because Aggarwal expressly relies on the swagger file as "the single source of truth" for the test logic (Aggarwal, Section "Benefits: 2. Increased Test efficiency"), and CacheControl expressly states its purpose is to "fail tests when swagger documentation is missing or inaccurate" (CacheControl, README "Synopsis"), providing a known mechanism for enforcing synchronization between test calls and the swagger specification. The combination is no more than the use of a known technique to improve a similar method in the same way, yielding the predictable result of a spreadsheet-driven API testing framework that verifies each API call defined by a thread of the test case script against the swagger file before transmission. With respect to claim 16 (currently amended), Aggarwal in view of Liu in view of Khawaja is silent to disclose, however in an analogous art, CacheControl teaches in response to determining that there is a mismatch with the expected status code and values, specify that the second thread failed; and in response to determining that there is no mismatch with the expected status code and values, specify that the second thread pass (CacheControl discloses that the framework reports the per-call test as failing when the response does not match the expected status code or values, and as passing otherwise. CacheControl, README "Synopsis" ("any request or response details not matching the swagger file will throw an appropriate exception, failing the spec"); README "Validations" ("hippie-swagger detects it is interacting with the app in ways not specified in the swagger file, it will throw an error and fail the test"). When all .expectStatus/.expectValue checks pass (no mismatch), no exception is thrown and the test is reported passing; otherwise the test is reported failing — reading on the recited pass/fail thread-status reporting based on mismatch versus no mismatch).
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 spreadsheet-driven API testing framework of Aggarwal to incorporate CacheControl’s per-call API verification process and mismatch-error reporting. The motivation arises because Aggarwal expressly relies on the swagger file as "the single source of truth" for the test logic (Aggarwal, Section "Benefits: 2. Increased Test efficiency"), and CacheControl expressly states its purpose is to "fail tests when swagger documentation is missing or inaccurate" (CacheControl, README "Synopsis"), providing a known mechanism for enforcing synchronization between test calls and the swagger specification. The combination is no more than the use of a known technique to improve a similar method in the same way, yielding the predictable result of a spreadsheet-driven API testing framework that verifies each API call defined by a thread of the test case script against the swagger file before transmission. With respect to claim 17 (currently amended), Aggarwal in view of Liu in view of Khawaja is silent to disclose, however in an analogous art, CacheControl teaches in response to detecting the mismatch between the first API call and the resource listing file, generate the error report to specify that an API cannot be found (CacheControl discloses that when the API call’s path or method is not found in the swagger file, the framework generates an error report specifying so. CacheControl, README "Validations: Paths" ("Swagger spec does not define path: pathNotMentionedInSwagger"); README "Validations: Method validation" ("Swagger spec does not define method: ‘post’ in path /users"). The plain-language error reports specifying that the API (path/method) cannot be found in the swagger file read on the recited "generate the error report to specify that an API cannot be found.").
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 spreadsheet-driven API testing framework of Aggarwal to incorporate CacheControl’s per-call API verification process and mismatch-error reporting. The motivation arises because Aggarwal expressly relies on the swagger file as "the single source of truth" for the test logic (Aggarwal, Section "Benefits: 2. Increased Test efficiency"), and CacheControl expressly states its purpose is to "fail tests when swagger documentation is missing or inaccurate" (CacheControl, README "Synopsis"), providing a known mechanism for enforcing synchronization between test calls and the swagger specification. The combination is no more than the use of a known technique to improve a similar method in the same way, yielding the predictable result of a spreadsheet-driven API testing framework that verifies each API call defined by a thread of the test case script against the swagger file before transmission.
With respect to claim 18, the claim is directed to a non-transitory machine readable medium that corresponds to the method recited in claim 1, respectively (see the rejection of claim 1 above). The additional structural elements of claim 18 (a non-transitory machine readable medium comprising instructions for performing the method) are inherent in each of the cited references and are otherwise within the level of ordinary skill in the art, as further detailed in the rejection of claim 1 above. With respect to claim 19 (original), Aggarwal in view of CacheControl in view of Khawaja is silent to disclose, however in an analogous art, Liu teaches populate a control flag cell with at least one of a skip control value, a jump control value, an exit control value, pause control value, a thread control value, a batch control value, a test log control value, a status control value, a test verification control value, a serial mode flow control value, or a quick mode flow control value (Liu et al. discloses populating a control flag cell with several of the enumerated control values via the Control Spreadsheet. Liu et al., Table I and Section III.B.1 "Control," page 1183: the "Tag" cell (Execution Flag) corresponds to a skip control value and/or a status control value (Section III.A, page 1182: "the symbol Tag is necessary control to select the appropriate branch of test case"); the "NextFlow" cell (Next Control Spreadsheet) corresponds to a jump control value; the "LogFile" cell (Test Log File Name) corresponds to a test log control value. Because claim 19 requires only "at least one of" the enumerated control values, the teaching of any single one (e.g., LogFile = test log control value) is sufficient. The per-row population of LogFile/Tag/NextFlow control flag cells reads on the recited "populate a control flag cell with at least one of" the enumerated control values.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Aggarwal in view of CacheControl to incorporate Liu’s control-spreadsheet structure, in which per-row control values direct the execution flow and continue execution after a per-row failure. The motivation arises because CacheControl provides per-call mismatch detection but is silent on the framework-level response to a per-call failure, and Liu et al. provides the framework-level continuation mechanism by which a single failure does not halt the broader execution flow (Liu, Abstract, page 1181, identifying this as making the framework "easy to maintain"). The combination is the use of a known technique to improve a similar method in the same way, yielding the predictable result of a spreadsheet-driven API testing framework in which per-row control values direct the execution flow and execution continues for verified threads while the failed thread is skipped.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Dheeraj Kumar Aggarwal (“Boost your API Test efficiency using swagger and excel sheets”, hereinafter Aggarwal) in view of CacheControl (“Hippie-Swagger”, hereinafter CacheControl) in view of Zhenyu Liu et al. (“A Maintainability Spreadsheet-Driven Regression Test Automation Framework”, hereinafter Liu) in view of Hassan Khawaja ("Automated API Testing using Postman and Excel”, hereinafter Khawaja) and further in view of Applicant’s Admitted Prior Art ("AAPA"). With respect to claim 7 (currently amended), Aggarwal teaches executing the operational step to perform [[at least one of a volume create operation, a volume deletion operation, a backup operation, or a storage operation associated with storage of the computing environment.]] (Aggarwal discloses execution of an operational step of the test upon a resource of the computing environment via an API call transmitted to a swagger-defined API endpoint. Aggarwal, Section "Process" (executing the generated test against the application under test); Section "Benefits". The generic API operation execution reads on the recited "executing the operational step" portion of the limitation.)). Aggarwal in view of CacheControl in view of Liu in view of Khawaja is silent to disclose, however in an analogous art, Applicant’s Admitted Prior Art teaches at least one of a volume create operation, a volume deletion operation, a backup operation, or a storage operation associated with storage of the computing environment (Applicant’s Admitted Prior Art (AAPA), at present specification paragraph [0001], expressly admits that storage software operations including creating volumes, deleting volumes (and snapshots), and data replication were performed by storage software prior to the present invention and were conventionally tested using test automation frameworks: "the test automation framework allows a developer to test software within a particular computing environment such as to determine whether storage software is capable of successfully creating volumes, renaming volumes, creating snapshots, deleting snapshots, replicating data, etc." (present specification, paragraph [0001]). See MPEP § 2129. The admitted volume, snapshot, and replication operations read on the recited "a volume create operation, a volume deletion operation, a backup operation, or a storage operation associated with storage of the computing environment."). 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 combination of Aggarwal in view of CacheControl, Liu, and Khawaja such that the operational step performed by the test framework is at least one of a volume create operation, a volume deletion operation, a backup operation, or a storage operation associated with storage of the computing environment, as admitted by AAPA to be conventional storage operations conventionally tested using test automation frameworks. The combined framework of Aggarwal in view of CacheControl, Liu, and Khawaja is a generic API testing framework that can be applied to test any API of a computing environment, and the storage APIs admitted by AAPA as known and conventionally tested are precisely the kind of APIs that this generic framework was designed to test. The application of the framework to a known type of API to be tested is the routine and predictable use of the framework.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Dheeraj Kumar Aggarwal (“Boost your API Test efficiency using swagger and excel sheets”, hereinafter Aggarwal) in view of CacheControl (“Hippie-Swagger”, hereinafter CacheControl) in view of Zhenyu Liu et al. (“A Maintainability Spreadsheet-Driven Regression Test Automation Framework”, hereinafter Liu) in view of Hassan Khawaja ("Automated API Testing using Postman and Excel”, hereinafter Khawaja) and further in view of Hruska et al. (US Pat. No. 9,612,940, hereinafter Hruska).
With respect to claim 10 (currently amended), Aggarwal in view of CacheControl in view of Liu in view of Khawaja is silent to disclose, however in an analogous art, Hruska teaches implementing a control panel for one or more test cases of the testing spreadsheet to override test control values, flow control values, step-level values, or thread-level values defined by the testing spreadsheet for the test cases, wherein a modification to the control panel modifies a test case without modifying values of steps or threads within the testing spreadsheet defined for the test case, and wherein the control panel is populated with a run threads field used to specify one or more threads in one or more steps to execute (Hruska discloses an automated test environment in which test parameters are defined and stored separately from the test methods, and in which the user identifies a particular parameter or parameter value at runtime to control which portions of the test suite execute, without modifying the underlying test method definitions. Hruska, column 2 lines 10-21 ("a mechanism to define parameter values and to specify which test methods use the parameters," each parameter "defined separately"); Column 13 lines 11-20 (FIG. 7C: "generates a user interface 730 for inputting identification of a particular parameter or a particular parameter value" that the user provides "when the user wants to execute only the test methods that reference the particular parameter or parameter value"); Column 11 lines 39-52 (FIG. 6, block 620) and column 18 lines 38-51 (FIG. 10, block 1040) (selectIf command "subsuite=suite.selectIf(‘ParameterName’, IsEqualTo(‘Param’))" identifying which elements of the test suite to execute); column 18 line 64 – column 19 line 12 (generating and executing a portion of the test suite); column 19 lines 23-33 ("execution of only a portion of the parameterized test may decrease execution time and may aid in debugging code"). The separate parameter-definition interface that overrides test method behavior without modifying the test methods, together with the selectIf-based identification of which subsuite to execute, reads on the recited "control panel . . . to override test control values, flow control values, step-level values, or thread-level values defined by the testing spreadsheet . . . without modifying values of steps or threads within the testing spreadsheet . . . wherein the control panel is populated with a run threads field used to specify one or more threads in one or more steps to execute."). 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 combination of Aggarwal in view of CacheControl, Liu, and Khawaja to incorporate Hruska’s control-panel mechanism (the parameter-identification user interface and selectIf command) that overrides the values used by the underlying test definitions and includes a run-threads field specifying which threads to execute, without modifying the underlying test definitions. The motivation arises because Liu et al. expressly teaches the value of separating the control definitions from the form (test step) definitions and the data definitions (Liu et al., Section III.B, page 1183), and Hruska, column 2 lines 10-21 and column 19 lines 23-33, expressly teaches the corresponding benefit of separating parameter definitions from test method definitions and that "execution of only a portion of the parameterized test may decrease execution time and may aid in debugging code." Applying Hruska’s known control-panel/run-threads mechanism to the spreadsheet-driven framework of Aggarwal in view of CacheControl, Liu, and Khawaja is the application of a known technique to a similar method in the same way to yield the predictable result of a test framework with a separate control panel that overrides the testing spreadsheet values without modifying the testing spreadsheet.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Dheeraj Kumar Aggarwal (“Boost your API Test efficiency using swagger and excel sheets”, hereinafter Aggarwal) in view of CacheControl (“Hippie-Swagger”, hereinafter CacheControl) in view of Zhenyu Liu et al. (“A Maintainability Spreadsheet-Driven Regression Test Automation Framework”, hereinafter Liu) in view of Hassan Khawaja ("Automated API Testing using Postman and Excel”, hereinafter Khawaja) and further in view of Wybouw-Cognard (US Pub. No. 2002/0116153, hereinafter Wybouw).
With respect to claim 13 (currently amended), Aggarwal in view of CacheControl in view of Liu in view of Khawaja is silent to disclose, however in an analogous art, Wybouw teaches implement, during execution of the test, a debugger to generate debug logs (Wybouw discloses a test automation framework that, during test execution, generates log files and provides an express command-line debug option for producing internal diagnostic output to trace and fix problems. Wybouw, paragraph [0066] (during test execution "the preparation step 28 is provided with a prepare log file 30 . . . a developer may subsequently follow the prepare process to determine how it was conducted and to establish where an error occurred"); paragraph [0070] ("the run means produces a run log file 40. The log file records all of the operations in the run process such that the user can subsequently view all of the steps in the process and determine the cause of any errors"); paragraph [0073] (verify log file produced for the verify step); paragraph [0122] (TABLE 1, -debug option: "[t]o be used to report a test automation framework defect. It prints internal information helpful to trace a problem and fix it"). The -debug option that invokes a debugger during test execution and that prints internal diagnostic information (recorded alongside the prepare, run, and verify log files) reads on the recited "implement, during execution of the test, a debugger to generate debug logs.").
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 combination of Aggarwal in view of CacheControl, Liu, and Khawaja to incorporate Wybouw’s debugger that is implemented during test execution and that generates debug logs. The motivation arises because Liu et al. teaches that the test framework should be "easy to maintain" (Liu, Abstract, page 1181), and Wybouw, paragraphs [0066], [0070], [0073], and [0122], teaches that providing log files of prepare/run/verify operations together with an express debug option that prints internal diagnostic information during test execution enables a developer to follow the process and "report a test automation framework defect" — directly serving the maintainability concern recognized by Liu. Applying Wybouw’s known debugger-during-test-execution mechanism to the test framework of Aggarwal in view of CacheControl, Liu, and Khawaja is the application of a known technique to a similar method in the same way.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Dheeraj Kumar Aggarwal (“Boost your API Test efficiency using swagger and excel sheets”, hereinafter Aggarwal) in view of CacheControl (“Hippie-Swagger”, hereinafter CacheControl) in view of Zhenyu Liu et al. (“A Maintainability Spreadsheet-Driven Regression Test Automation Framework”, hereinafter Liu) in view of Hassan Khawaja ("Automated API Testing using Postman and Excel”, hereinafter Khawaja) in view of Hruska et al. (US Pat. No. 9,612,940, hereinafter Hruska) and further in view of Wybouw-Cognard (US Pub. No. 2002/0116153, hereinafter Wybouw).
With respect to claim 20 (original), Aggarwal in view of CacheControl in view of Liu in view of Khawaja in view of Wybouw is silent to disclose, however in an analogous art, Hruska teaches [[utilize a command line parameter]] to alter a value of a variable within the testing spreadsheet for a test case at runtime, wherein the test case is run for different test scenarios using override values [[input through the command line parameter]] without modifying original values within the testing spreadsheet (Hruska discloses that parameter values used by test methods are defined and stored separately from the test method source, and that the user supplies values at runtime which are applied to the test methods to produce different test executions without modifying the underlying test methods. Hruska, column 2 lines 10-21 ("mechanism to define parameter values and to specify which test methods use the parameters," each parameter "defined separately"); Column 7 lines 51-67 (parameter-properties syntax: "properties (TestParameter) Param=(A, B, C); end"); Column 13 lines 11-27 (user interface for identifying particular parameters/values at runtime); Column 18 lines 5-24 (user provides parameter properties applied at runtime); Column 19 lines 23-33 ("parameterized testing may involve executing the same set of test methods multiple times with varying test parameters" without modifying the test methods). The runtime supply of override parameter values that vary test execution across runs without modifying the underlying test definitions reads on the recited "alter a value of a variable within the testing spreadsheet for a test case at runtime, wherein the test case is run for different test scenarios using override values . . . without modifying original values within the testing spreadsheet."). 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 combination of Aggarwal in view of CacheControl, Liu et al., and Khawaja to incorporate Hruska’s runtime parameter-value override mechanism in which override values are supplied separately and applied at runtime without modifying the original test source. The motivation arises because Liu et al. teaches that the testers should be able to vary the testing readily across different testing requirements ("the testers merely need to modify the related definition in spreadsheet," Liu et al., Section III.A, page 1182), and Hruska, column 2 lines 10-21 and column 19 lines 23-33, expressly teaches that supplying parameter values separately and applying them at runtime enables "executing the same set of test methods multiple times with varying test parameters" without modifying the test method definitions.
Aggarwal in view of CacheControl in view of Liu in view of Khawaja in view of Hruska is silent to disclose, however in an analogous art, Wybouw teaches utilize a command line parameter (Wybouw discloses an express command-line interface for the test automation framework. Wybouw, paragraphs [0118]–[0120] (the taf command, syntax "taf [options] [all/ALL/topicExpression]", which "controls the building, execution and verification of the scenarios" and "includes a number of parameters and options"); Paragraph [0122] (TABLE 1: command-line options including -v, -mail, -verbose, -debug, -batch, -clobber, -nobuild, -noexec, -nocheck, -noprologue, -noreport). The taf command and its accompanying command-line options read on the recited "utilize a command line parameter."). input through the command line parameter (Wybouw further discloses that the values controlling the framework’s runtime behavior are supplied to the framework as inputs through the command-line parameters of the taf command. Wybouw, paragraph [0119] ("taf [options] [all/ALL/topicExpression]," in which the [options] are the command-line parameter values input by the user); paragraph [0120] ("The first form of the command is used to control the build, execution and verification of the scenarios . . . [t]he second form is used to delete files created during the previous test execution", both forms operating on values input through the command-line parameters); paragraph [0122] (TABLE 1, each option being a value input through the command-line parameter that alters the framework’s behavior, e.g., -batch "[c]hanges the default behaviour of the taf command"; -noexec "[d]oes not execute the run process"; -nocheck "[d]oes not run the verify process"). The supply of values via the command-line options of the taf command reads on the recited "input through the command line parameter.").
It would have been further obvious to incorporate Wybouw’s command-line interface (the taf command and its command-line options) as the delivery mechanism for the runtime override values taught by Hruska. The motivation arises because Wybouw, paragraphs [0118]–[0122], teaches that delivering runtime control to a test automation framework via command-line options of an express test-automation command is a known and well-defined mechanism for controlling runtime behavior of the framework without modifying the underlying scenario definitions. Combining Wybouw’s command-line interface with Hruska’s runtime value-override mechanism, and applying the combination to the spreadsheet-driven framework of Aggarwal in view of CacheControl, Liu et al., and Khawaja, is the application of a known technique to a similar method in the same way to yield the predictable result of a test framework in which a command-line parameter alters a value of a variable within the testing spreadsheet for a test case at runtime, with the test case run for different test scenarios using the override values without modifying the original values within the testing spreadsheet.
Allowable Subject Matter
Claims 2, 5 and 9 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.
Conclusion
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 ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6: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 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights