DETAILED ACTION
Remarks
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office action is filed in response to Applicant’s arguments and amendment dated March 4, 2026. Claims 1, 8, and 15 are currently amended and claims 1-20 remain pending in the application and have been fully considered by Examiner.
Applicant's arguments with respect to the prior art rejections have been considered but are moot in view of the new grounds of rejection presented herein.
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.
Claim Objections
Claims 8-14 are objected to because of the following informalities:
With respect to claim 8, lines 1-2 recite “A method for generating test suite suites for an application programming interfaces (APIs)”, which appears to be a typographical error that should recite -- A method for generating test suite suites for [[an]] application programming interfaces (APIs) --.
With respect to claims 9-14, each inherits the deficiency of the claim 8 above.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
With respect to claim 1, lines 7-10 recite “one or more models configured to process the specification using one or more artificial intelligence techniques” and lines 10-11 recite “wherein the one or more models receive the specification as an input and provide the test object as an output”. Thus, according to claim 1, the same model or models “process the specification”, “receive the specification as an input”, and “provide the test object as an output”. However, the relevant portions of Applicant’s specification disclose that receiving and processing the API specification is performed by a single model and providing the test object as an output is performed by a different model. In more detail, Applicant’s specification recites, with emphasis added, (1) “The API specification parsing model may be a model configured to process an API specification to identify a plurality of attributes based on which a test object can be generated … the API specification parsing model may be configured or trained using one or more artificial intelligence (AI) techniques”1 and (2) “a test object model configured to process the plurality of specification attributes, the set of test case rules, and the test case dataset to determine the set of test cases and generate the test object … the test object model may be configured or trained using one or more AI techniques”2.
As there is nothing in the originally filed application that discloses either explicitly, implicitly, or inherently, that the same model or models receives and processes the API specification and outputs the test object, claim 1 contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
With respect to claims 8 and 15, each recites limitations similar to those identified above with respect to claim 1 and are therefore also rejected under 35 USC 112(a).
With respect to all dependent claims, each inherits the 35 USC 112(a) deficiency of its respective base claim (see the rejections of claim 1, 8, and 15 above).
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, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ed-douibi “Automatic Generation of Test Cases for REST APIs: a Specification-Based Approach” (hereinafter Ed-douibi) in view of Bhalaik “ChatGPT x Cypress.io API tests [shorts]” (hereinafter Bhalaik), Satabdi “Building A Scalable API Testing Framework With Jest And SuperTest” (hereinafter Satabdi) and Anonymous, “What is API testing, and everything there is to know about it” (hereinafter Anonymous).
With respect to claim 1, Ed-douibi discloses A system for generating test suites for application programming interfaces (APIs) (e.g., Fig. 1 on p. 184 and Fig. 6 on p. 188 and associated text, e.g., p. 1, right column, last para., we propose an approach to generate test cases for REST APIs relying on their specifications; p. 187, § IX. Tool Support, We created a proof-of-concept plugin implementing our approach. The plugin extends the Eclipse platform.), the system comprising:
one or more memories; and one or more processors, communicatively coupled to the one or more memories (Id.), configured to:
obtain a specification associated with an API (e.g., Fig. 1 on p. 184 and associated text, e.g., p. 183, § IV. Our Approach, We define an approach to automate specification-based REST API testing, which we illustrate using the OpenAPI specification, as shown in Figure 1 … The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON (or YAML) file.);
generate, , a framework agnostic test object based on the specification associated with the API, wherein the test object comprises information associated with a set of test cases for the API (e.g., Figs. 1-6 on pp. 184-188 and associated text, e.g., p. 183, right column, § IV., 2nd para., The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON (or YAML) file [based on the specification] … The third step generates a TestSuite model from the OpenAPI model by inferring test case definitions for the API operations; p. 185, §VII Extracting Test Case Definitions, We start by introducing the TestSuite metamodel, used to represent test case definitions … A. The Test Suite Metamodel, The TestSuite metamodel allows creating test case definitions for REST APIs [generate a test object] … The TestSuite element represents a test suite and is the root element of our metamodel. This element includes a name, the URL of the REST API definition (i.e., api attribute), and a set of test case definitions … The TestCase element represents a test case definition and includes a name, a description, and a set of test steps (i.e., testSteps references); p. 187, right column, VIII. Code Generation … Since the test case definitions are platform-independent, any programing language or testing tool could be considered [framework agnostic].), and wherein receive the specification as an input and provide the test object as an output (e.g., Figs. 1-6 on pp. 184-188 and associated text, e.g., p. 183, right column, § IV., 2nd para., The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON (or YAML) file [receive the specification as input] … The third step generates a TestSuite model from the OpenAPI model by inferring test case definitions for the API operations; p. 185, §VII Extracting Test Case Definitions, In the following we explain the generation process of test case definitions [provide the test object as an output] … A. The Test Suite Metamodel, The TestSuite metamodel allows creating test case definitions for REST APIs.);
identify a framework associated with a test suite to be generated for the API (e.g., Figs. 1 on p. 184 and Figs. 5-6 on p. 188 and associated text, e.g., p. 183, § IV., 2nd para., Finally the last step transforms the TestSuite model into executable code (JUnit [framework] in our case); p. 187, right column, § VIII. Code Generation, The final step of the process consists on generating test cases for a target platform. Since the test case definitions are platform-independent, any programing language or testing tool could be considered. In Section IX we will illustrate our approach for Java programming language and JUnit … The generated classes rely on JUnit to validate the tests.);
apply the framework to the test object to generate the test suite for the API, wherein the test suite enables API testing (e.g., Fig. 1 on p. 184 and Figs. 5-6 on p. 188 and associated text, e.g., p. 181, right col., last para., Models conforming to this metamodel are created from REST API definitions, and later used to generate the executable code to test the API; p. 183, § IV., 2nd para., Finally the last step transforms the TestSuite model into executable code (JUnit [framework] in our case); p. 187, § VIII. Code Generation, The final step of the process consists on generating test cases for a target platform; p. 187, § IX, 2nd para., Finally, we used Acceleo to generate the JUnit test cases [test suite].); and
provide information associated with the test suite for the API (e.g., Figs. 5-6 on p. 188 and associated text, e.g., p. 187, § IX. Tool Support, 3rd para., Figure 6 shows a screenshot of the generated Maven project for the Petstore API including the corresponding tests for test cases showed in Figure 5; p. 189, § B. Results, Once we built our collection, we ran our tool for each REST API to generate and execute the test cases.).
Ed-douibi does not appear to disclose the following, which is taught in analogous art, Bhalaik: using one or more models configured to process the specification using one or more artificial intelligence techniques (e.g., p. 1, 2nd – 3rd paras., generate all my test scenarios … using OpenAI ChatGPT … OpenAI ChatGPT is a conversation language model; p. 6, 1st screenshot, generate test scenarios based on following swagger.json [API specification]; p. 7, lines 4-12,
The following is an example of a basic test scenario based on the Swagger.json:
· Test GET /faqs endpoint:
· Send a GET request to the /faqs endpoint
· Verify that the status code of the response is 200
· Verify that the response content type is "application/json"
· Verify that the response body is a JSON array.)
… the one or more models (Id.; p. 1, 2nd – 3rd paras., generate all my test scenarios … using OpenAI ChatGPT … OpenAI ChatGPT is a conversation language model; p. 6, 1st screenshot, generate test scenarios based on following swagger.json; p. 7, lines 4-5, The following is an example of a basic test scenario based on the Swagger.json; see also p. 6, 2nd screenshot.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Ed-douibi with the technique of Bhalaik, such that the ChatGPT conversation language model is used to process an API specification and output a test object, because ChatGPT is effective, user-friendly, and readily accessible via the web.
Although Ed-douibi discloses a framework (see above), it does not appear to disclose the following, which is taught in analogous art, Satabdi: user-defined or user-customized (e.g., p. 3, last para., We can overcome such annoyance and meet our purpose using a self-built Jest framework using SuperTest; p. 5, last para., Jest configurations: Note: This is customizable as per requirements).
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 invention of Ed-douibi with the invention of Satabdi, such that that the testing framework is user created, because it offers numerous benefits, such as it being “Customizable” and it “Saves you from the trap of limitations of a ready-made tool,” as suggested by Satabdi (see p. 2, last para.).
Although Ed-douibi discloses API testing (see above), it does not appear to disclose the following, which is taught in analogous art, Anonymous: one-shot (e.g., p. 3, § Types of API Testing, There are different types of testing, when you put an API for testing. Here are the different types of API testing: … Unit testing is that in which testing is done to a single endpoint, with a single request, looking for a single response.).
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 invention of Ed-douibi with the invention of Anonymous, such that the API testing includes unit tests for one-shot API testing, because such tests are simple and quick to write.
With respect to claim 8, Ed-douibi discloses A method for generating test suites for application programming interface (APIs) (e.g., Fig. 1 on p. 184 and Fig. 6 on p. 188 and associated text, e.g., p. 1, right column, we propose an approach to generate test cases for REST APIs relying on their specifications; p. 187, section IX. Tool Support, We created a proof-of-concept plugin implementing our approach. The plugin extends the Eclipse platform.), comprising:
generating, by a system , a framework agnostic object based on the specification, wherein the object includes information associated with at least one test case associated with the API (e.g., Figs. 1-6 on pp. 184-188 and associated text, e.g., p. 183, § IV., 2nd para., The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON (or YAML) file … The third step generates a TestSuite model [framework agnostic object] from the OpenAPI model by inferring test case definitions for the API operations; p. 185, §VII Extracting Test Case Definitions, … The TestSuite metamodel allows creating test case definitions for REST APIs … The TestSuite element represents a test suite and is the root element of our metamodel. This element includes a name, the URL of the REST API definition (i.e., api attribute), and a set of test case definitions … The TestCase element represents a test case definition and includes a name, a description, and a set of test steps (i.e., testSteps references); p. 187, § VIII. Code Generation … Since the test case definitions are platform-independent, any programing language or testing tool could be considered [framework agnostic].), and wherein receive the specification as an input and provide the object as an output (e.g., Figs. 1-6 on pp. 184-188 and associated text, e.g., p. 183, right column, § IV., 2nd para., The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON (or YAML) file [receive the specification as input] … The third step generates a TestSuite model from the OpenAPI model by inferring test case definitions for the API operations [provide the test object as an output]; p. 185, §VII Extracting Test Case Definitions, In the following we explain the generation process of test case definitions [provide the object as an output] … A. The Test Suite Metamodel, The TestSuite metamodel allows creating test case definitions for REST APIs.);
identifying, by the system, a framework to be applied to the object in association with generating a test suite for the API (e.g., Figs. 1 on p. 184 and Figs. 5-6 on p. 188 and associated text, e.g., p. 183, right column, IV. Our Approach … Finally the last step transforms the TestSuite model into executable code (JUnit in our case); p. 187, § VIII. Code Generation, The final step of the process consists on generating test cases for a target platform. Since the test case definitions are platform-independent, any programing language or testing tool could be considered. In Section IX we will illustrate our approach for Java programming language and JUnit [framework] … The generated classes rely on JUnit to validate the tests.);
applying, by the system, the framework to the object to generate the test suite for the API, wherein the test suite enables API testing (e.g., Figs. 1 on p. 184 Figs. 5-6 on p. 188 and associated text, e.g., p. 181, right col., last para., Models conforming to this metamodel are created from REST API definitions, and later used to generate the executable code to test the API; p. 183, § IV, 2nd para., Finally the last step transforms the TestSuite model into executable code (JUnit [framework] in our case); p. 187, § VIII. Code Generation, The final step of the process consists on generating test cases for a target platform; p. 187, § IX, 2nd para., Finally, we used Acceleo to generate the JUnit test cases [test suite].); and
providing, by the system, information associated with the test suite (e.g., Figs. 5-6 on p. 188 and associated text, e.g., p. 187, section IX. Tool Support, Figure 6 shows a screenshot of the generated Maven project for the Petstore API including the corresponding tests for test cases showed in Figure 5; p. 189, § B. Results, Once we built our collection, we ran our tool for each REST API to generate and execute the test cases.).
Ed-douibi does not appear to disclose the following, which is taught in analogous art, Bhalaik: and using one or more models configured to process a specification associated with an API using one or more artificial intelligence techniques (e.g., p. 1, 2nd – 3rd paras., generate all my test scenarios … using OpenAI ChatGPT … OpenAI ChatGPT is a conversation language model; p. 6, 1st screenshot, generate test scenarios based on following swagger.json [API specification]; p. 7, lines 4-12,
The following is an example of a basic test scenario based on the Swagger.json:
· Test GET /faqs endpoint:
· Send a GET request to the /faqs endpoint
· Verify that the status code of the response is 200
· Verify that the response content type is "application/json"
· Verify that the response body is a JSON array.)
… the one or more models (Id.; p. 1, 2nd – 3rd paras., generate all my test scenarios … using OpenAI ChatGPT … OpenAI ChatGPT is a conversation language model; p. 6, 1st screenshot, generate test scenarios based on following swagger.json; p. 7, lines 4-5, The following is an example of a basic test scenario based on the Swagger.json; see also p. 6, 2nd screenshot.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Ed-douibi with the technique of Bhalaik, such that the ChatGPT conversation language model is used to process an API specification and output a test object, because ChatGPT is effective, user-friendly, and readily accessible via the web.
Although Ed-douibi discloses a framework (see above), it does not appear to disclose the following, which is taught in analogous art, Satabdi: user-defined or user-customized (e.g., p. 3, last para., We can overcome such annoyance and meet our purpose using a self-built Jest framework using SuperTest; p. 5, last para., Jest configurations: Note: This is customizable as per requirements).
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 invention of Ed-douibi with the invention of Satabdi, such that that the testing framework is user created, because it offers numerous benefits, such as it being “Customizable” and it “Saves you from the trap of limitations of a ready-made tool,” as suggested by Satabdi (see p. 2, last para.).
Although Ed-douibi discloses API testing (see above), it does not appear to disclose the following, which is taught in analogous art, Anonymous: one-shot (e.g., p. 3, § Types of API Testing, There are different types of testing, when you put an API for testing. Here are the different types of API testing: Unit testing … is that in which testing is done to a single endpoint, with a single request, looking for a single response or set of responses.).
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 invention of Ed-douibi with the invention of Anonymous, such that the API testing includes unit tests for one-shot API testing, because such tests are simple and quick to write.
With respect to claim 2, Ed-douibi also discloses wherein the one or more processors, to generate the test object, are configured to: identify a plurality of specification attributes based on the specification associated with the API (e.g., Figs. 2-5 on pp. 184-187 and associated text, e.g., p. 183, right column, § IV. 2nd para., The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON … file; p. 184, § B. Extraction Process, Creating OpenAPI models from JSON … OpenAPI definitions [API specification] is rather straightforward as our metamodel mirrors the structure of the OpenAPI specification … Thus, the root object of the JSON file is transformed to an instance of the API model element, then each JSON field is transformed to its corresponding model element.), and generate the test object based on the plurality of specification attributes (e.g., Figs. 2-5 on pp. 184-188 and associated text, e.g., p. 183, IV., 2nd para., The third step generates a TestSuite model from the OpenAPI model by inferring test case definitions for the API operations; p. 187, left column, last para., Figure 5 shows an example of nominal and faulty test cases for the operation findPetsByStatus of Petstore represented as a model conforming to our TestSuite metamodel.).
With respect to claim 3, Ed-douibi also discloses wherein the one or more processors, to generate the test object, are configured to: identify a set of test case rules (e.g., Fig. 1 on p. 184, Fig. 4 on p. 186, and Fig. 5 on p. 188 and associated text, e.g., pp. 186-187, § VII. B. OpenAPI to TestSuite Transformation, 1st para., We define two rules (i.e., GR 1 and GR 2) to generate test case definitions in order to assess that the REST APIs behave correctly using both correct and incorrect data inputs.), and determine the information associated with the set of test cases based on the set of test case rules (Id.; p. 186, § VII. B. OpenAPI to TestSuite Transformation, 1st - 2nd para., GR 1 (Nominal test case definition). If an operation o is testable then one TestCase testing such operation is generated … GR 2 (Faulty test case definition). For each parameter p in an operation o, a TestCase testing such operation is generated.).
With respect to claim 4, Ed-douibi also discloses wherein the one or more processors, to generate the test object, are configured to: determine a test case dataset (e.g., Figs. 1-6 and associated text, e.g., p. 183, § IV. Our Approach, 2nd para., The second step extends the created OpenAPI model to add parameter examples, which will be used as input data in the test cases; p. 184, § VI. Inferring Parameter Values, The goal of this step is to enrich OpenAPI models with the parameter values needed to generate test cases for an operation.), and determine the information associated with the set of test cases based on the test case dataset (Id., particularly, 184, § VI. Inferring Parameter Values, the parameter values needed to generate test cases for an operation; p. 186, § VII. B. OpenAPI to TestSuite Transformation, 2nd para., GR 1 (Nominal test case definition). If an operation o is testable then one TestCase testing such operation is generated such as APIRequest includes the inferred required parameter values.).
With respect to claim 5, Ed-douibi also discloses wherein the one or more processors, to determine the test case dataset, are configured to determine the test case dataset based on at least one of the specification associated with the API, data traffic associated with the API, or user input (e.g., Figs. 1-6 and associated text, e.g., p. 184, § VI. Inferring Parameter Values … PR 3 (Complex parameter value inference). A value of a parameter p could be inferred from the response of an operation o if: (1) o is testable; (2) o returns a successful response r; and (3) r.schema contains a property matching p; p. 185, left column, top para., Note that PR 2 and PR 3 stress the API (i.e., they involve sending several requests to the API) [determine the test case dataset based on data traffic associated with the API].).
With respect to claim 7, Ed-douibi also discloses wherein the set of test cases includes at least one test case associated with an API response (e.g., Figs. 5-6 on p. 188 and associated text, e.g., pp. 186-187, § VII. B. OpenAPI to TestSuite Transformation….GR 1 generates nominal test case definitions which assess that given correct input data, the API operations return a successful response code (i.e., 2xx family of codes) and respect their specification. GR 2 generates faulty test case definitions which assess that given incorrect input data, the API operations return a client error response code (i.e., 4xx family of codes); p. 183, left column, section C. Specification-based API Testing, In specification-based REST API testing, test cases consist of sending requests over HTTP/S and validating that the server responses conform to the specification.).
With respect to claim 9, Ed-douibi also discloses wherein the generating the object comprises: analyzing the specification to identify a plurality of specification attributes (e.g., Figs. 2-5 on pp. 184-188 and associated text, e.g., p. 183, right column, § IV. 2nd para., The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON … file; p. 184, § B. Extraction Process, Creating OpenAPI models from JSON … OpenAPI definitions [API specification] is rather straightforward as our metamodel mirrors the structure of the OpenAPI specification … Thus, the root object of the JSON file is transformed to an instance of the API model element, then each JSON field is transformed to its corresponding model element.), and generating the object based on the plurality of specification attributes (e.g., Figs. 2-5 on pp. 184-188 and associated text, e.g., p. 183, IV., 2nd para., The third step generates a TestSuite model [object] from the OpenAPI model by inferring test case definitions for the API operations; p. 187, left column, last para., Figure 5 shows an example of nominal and faulty test cases for the operation findPetsByStatus of Petstore represented as a model conforming to our TestSuite metamodel.).
With respect to claim 10, Ed-douibi also discloses wherein the generating the object comprises determining the information associated with the at least one test case based on a set of test case rules (e.g., Fig. 1 on p. 184, Fig. 4 on p. 186, and Fig. 5 on p. 188 and associated text, e.g., pp. 186-187, § VII. B. OpenAPI to TestSuite Transformation, … We define two rules (i.e., GR 1 and GR 2) to generate test case definitions in order to assess that the REST APIs behave correctly using both correct and incorrect data inputs … GR 1 (Nominal test case definition). If an operation o is testable then one TestCase testing such operation is generated … GR 2 (Faulty test case definition). For each parameter p in an operation o, a TestCase testing such operation is generated.).
With respect to claim 11, Ed-douibi also discloses wherein the generating the object comprises determining the information associated with the at least one test case based on a test case dataset (e.g., Figs. 1-6 and associated text, e.g., p. 183, § IV. Our Approach, 2nd para., The second step extends the created OpenAPI model to add parameter examples, which will be used as input data in the test cases; p. 184, § VI. Inferring Parameter Values, The goal of this step is to enrich OpenAPI models with the parameter values needed to generate test cases for an operation; p. 186, § B. OpenAPI to TestSuite Transformation, 2nd para., GR 1 (Nominal test case definition). If an operation o is testable then one TestCase testing such operation is generated such as APIRequest includes the inferred required parameter values.).
With respect to claim 12, Ed-douibi also discloses wherein the test case dataset is based on at least one of the specification, data traffic associated with the API, or user input (e.g., Figs. 1-6 and associated text, e.g., p. 184, § VI. Inferring Parameter Values … PR 3 (Complex parameter value inference). A value of a parameter p could be inferred from the response of an operation o if: (1) o is testable; (2) o returns a successful response r; and (3) r.schema contains a property matching p; p. 185, left column, top para., Note that PR 2 and PR 3 stress the API (i.e., they involve sending several requests to the API) [test case dataset is based on data traffic associated with the API].).
With respect to claim 13, Ed-douibi also discloses wherein the object is not specific to the user-defined or user-customized framework (e.g., Figs. 1-6 on pp. 184-188 and associated text, e.g., p. 185, §VII Extracting Test Case Definitions … The TestSuite element represents a test suite and is the root element of our metamodel. This element includes a name, the URL of the REST API definition (i.e., api attribute), and a set of test case definitions; p. 187, § VIII. Code Generation … Since the test case definitions are platform-independent, any programing language or testing tool could be considered [framework agnostic].).
With respect to claim 14, Ed-douibi also discloses wherein the at least one test case includes a test case for an API response (e.g., Figs. 5-6 on p. 188 and associated text, e.g., pp. 186-187, § VII. B. OpenAPI to TestSuite Transformation….GR 1 generates nominal test case definitions which assess that given correct input data, the API operations return a successful response code (i.e., 2xx family of codes) and respect their specification. GR 2 generates faulty test case definitions which assess that given incorrect input data, the API operations return a client error response code (i.e., 4xx family of codes); p. 183, left column, section C. Specification-based API Testing, In specification-based REST API testing, test cases consist of sending requests over HTTP/S and validating that the server responses conform to the specification.).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Ed-douibi in view of Bhalaik, Satabdi and Anonymous, as applied to claim 1 above, and further in view of Martin-Lopez “RESTest: Automated Black-Box Testing of RESTful Web APIs” (hereinafter Martin-Lopez).
With respect to claim 6, Ed-douibi also discloses wherein the test object is configured to generate (e.g., Figs. 1-6 and associated text, e.g., p. 181, right col., last para., Models conforming to this metamodel are created from REST API definitions, and later used to generate the executable code to test the API; p. 183, § IV., 2nd para., Finally the last step transforms the TestSuite model into executable code (JUnit [framework] in our case); p. 187, § VIII. Code Generation, Since the test case definitions are platform-independent, any programing language or testing tool could be considered; p. 187, § IX, 2nd para., Finally, we used Acceleo to generate the JUnit test cases [test suite].).
Although Ed-douibi discloses the test object configured to generate a test suite for a framework (see above), it does not appear to disclose the following, which is taught in analogous art, Martin-Lopez: test suites for a plurality of different frameworks (e.g., Figs. 1-2 on p. 683 and associated text, e.g., p. 682, right col., last para., The test cases can be instantiated into several frameworks and libraries such as REST Assured and Postman.).
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 invention of Ed-douibi with the invention of Martin-Lopez, such that test suites are generated for multiple frameworks, because it “can be easily extended with new test case generators and test writers for different programming languages” (see Abstract) and would allow different users to use their preferred framework.
Claims 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ed-douibi in view of Bhalaik, Martin-Lopez, and Anonymous.
With respect to claim 15, Ed-douibi discloses A non-transitory computer-readable medium storing a set of instructions (e.g., Fig. 1 on p. 184 and Fig. 6 on p. 188 and associated text, e.g., p. 1, right column, we propose an approach to generate test cases for REST APIs relying on their specifications; p. 187, section IX. Tool Support, We created a proof-of-concept plugin implementing our approach. The plugin extends the Eclipse platform.), the set of instructions comprising:
one or more instructions that, when executed by one or more processors of a system (Id.), cause the system to:
obtain a specification associated with an application programming interface (API) (e.g., Fig. 1 on p. 184 and associated text, e.g., p. 183, right column, § IV. Our Approach, We define an approach to automate specification-based REST API testing, which we illustrate using the OpenAPI specification, as shown in Figure 1 … The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON (or YAML) file.);
identify a plurality of specification attributes based on the specification (e.g., Figs. 2-5 on pp. 184-186 and associated text, e.g., p. 183, right column, § IV. 2nd para., The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON … file; p. 184, § B. Extraction Process, Creating OpenAPI models from JSON … OpenAPI definitions [API specification] is rather straightforward as our metamodel mirrors the structure of the OpenAPI specification … Thus, the root object of the JSON file is transformed to an instance of the API model element, then each JSON field is transformed to its corresponding model element.);
generate, , a framework agnostic test object based on the plurality of specification attributes, wherein the test object includes information associated with a plurality of test cases associated with testing the API (e.g., Figs. 2-5 on pp. 184-186 and associated text, e.g., p. 183, § IV., 2nd para., The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON (or YAML) file … The third step generates a TestSuite model from the OpenAPI model by inferring test case definitions for the API operations [generate a test object]; p. 185, §VII Extracting Test Case Definitions … The TestSuite metamodel allows creating test case definitions for REST APIs … The TestSuite element represents a test suite and is the root element of our metamodel. This element includes a name, the URL of the REST API definition (i.e., api attribute), and a set of test case definitions … The TestCase element represents a test case definition and includes a name, a description, and a set of test steps (i.e., testSteps references); p. 187, § VIII. Code Generation … Since the test case definitions are platform-independent, any programing language or testing tool could be considered [framework agnostic].), and wherein receive the specification as an input and provide the test object as an output (e.g., Figs. 1-6 on pp. 184-188 and associated text, e.g., p. 183, right column, § IV., 2nd para., The first step extracts an OpenAPI model from the definition document of a REST API, by parsing and processing the JSON (or YAML) file [receive the specification as input] … The third step generates a TestSuite model from the OpenAPI model by inferring test case definitions for the API operations. 185, §VII Extracting Test Case Definitions, In the following we explain the generation process of test case definitions [provide the test object as an output] … A. The Test Suite Metamodel, The TestSuite metamodel allows creating test case definitions for REST APIs);
generate a test suite for the API based on applying a particular framework to the test object (e.g., Figs. 1 on p. 184 Figs. 5-6 on p. 188 and associated text, e.g., p. 181, right col., last para., Models conforming to this metamodel are created from REST API definitions, and later used to generate the executable code to test the API; p. 183, right column, IV. Our Approach … Finally the last step transforms the TestSuite model into executable code (JUnit [framework] in our case); p. 187 § VIII. Code Generation, The final step of the process consists on generating test cases for a target platform; p. 187, § IX, 2nd para., Finally, we used Acceleo to generate the JUnit test cases [test suite].); and
provide information associated with the test suite based on performing API testing (e.g., Figs. 5-6 on p. 188 and associated text, e.g., p. 187, § IX. Tool Support, 3rd para., Figure 6 shows a screenshot of the generated Maven project for the Petstore API including the corresponding tests for test cases showed in Figure 5; p. 189, § B. Results, Once we built our collection, we ran our tool for each REST API to generate and execute the test cases.).
Ed-douibi does not appear to disclose the following, which is taught in analogous art, Bhalaik: using one or more models configured to process the specification using one or more artificial intelligence techniques (e.g., p. 1, 2nd – 3rd paras., generate all my test scenarios … using OpenAI ChatGPT … OpenAI ChatGPT is a conversation language model; p. 6, 1st screenshot, generate test scenarios based on following swagger.json [API specification]; p. 7, lines 4-12,
The following is an example of a basic test scenario based on the Swagger.json:
· Test GET /faqs endpoint:
· Send a GET request to the /faqs endpoint
· Verify that the status code of the response is 200
· Verify that the response content type is "application/json"
· Verify that the response body is a JSON array.)
… the one or more models (Id.; p. 1, 2nd – 3rd paras., generate all my test scenarios … using OpenAI ChatGPT … OpenAI ChatGPT is a conversation language model; p. 6, 1st screenshot, generate test scenarios based on following swagger.json; p. 7, lines 4-5, The following is an example of a basic test scenario based on the Swagger.json; see also p. 6, 2nd screenshot.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Ed-douibi with the technique of Bhalaik, such that the ChatGPT conversation language model is used to process an API specification and output a test object, because ChatGPT is effective, user-friendly, and readily accessible via the web.
Although Ed-Douibi discloses a particular framework (see above), it does not appear to disclose the following, which is taught in analogous art, Martin-Lopez: of a plurality of different frameworks (e.g., Figs. 1-2 on p. 683 and associated text, e.g., p. 682, right col., last para., The test cases can be instantiated into several frameworks and libraries such as REST Assured and Postman; p. 683, left col., last para., (3) Test case generation. Abstract test cases are instantiated into executable test cases using specific testing frameworks and libraries such as REST Assured.).
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 invention of Ed-douibi with the invention of Martin-Lopez, such that test suites can be generated for multiple frameworks, because it “can be easily extended with new test case generators and test writers for different programming languages” (see Abstract) and would allow different users to select their preferred framework.
Although Ed-Douibi discloses API testing (see above), it does not appear to disclose the following, which is taught in analogous art, Anonymous: one-shot (e.g., p. 3, § Types of API Testing, There are different types of testing, when you put an API for testing. Here are the different types of API testing: … Unit testing is that in which testing is done to a single endpoint, with a single request, looking for a single response or set of responses.).
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 invention of Ed-douibi with the invention of Anonymous, such that the API testing includes unit tests for one-shot API testing, because such tests are simple and quick to write.
With respect to claim 16, Ed-douibi also discloses wherein the one or more instructions, that cause the system to generate the test object, cause the system to: identify a set of test case rules (e.g., Fig. 1 on p. 184, Fig. 4 on p. 186, and Fig. 5 on p. 188 and associated text, e.g., pp. 186-187, § VII. B. OpenAPI to TestSuite Transformation, 1st para., We define two rules (i.e., GR 1 and GR 2) to generate test case definitions in order to assess that the REST APIs behave correctly using both correct and incorrect data inputs.), and determine the information associated with the plurality of test cases based on the set of test case rules (Id.; p. 186, § B. OpenAPI to TestSuite Transformation, 1st - 2nd para., GR 1 (Nominal test case definition). If an operation o is testable then one TestCase testing such operation is generated … GR 2 (Faulty test case definition). For each parameter p in an operation o, a TestCase testing such operation is generated.).
With respect to claim 17, Ed-douibi also discloses wherein the one or more instructions, that cause the system to generate the test object, cause the system to: determine a test case dataset (e.g., Figs. 1-6 and associated text, e.g., p. 183, § IV. Our Approach, 2nd para., The second step extends the created OpenAPI model to add parameter examples, which will be used as input data in the test cases; p. 184, § VI. Inferring Parameter Values, The goal of this step is to enrich OpenAPI models with the parameter values needed to generate test cases for an operation.), and determine the information associated with the plurality of test cases based on the test case dataset (Id., particularly, 184, § VI. Inferring Parameter Values, the parameter values needed to generate test cases for an operation; p. 186, § B. OpenAPI to TestSuite Transformation, 2nd para., GR 1 (Nominal test case definition). If an operation o is testable then one TestCase testing such operation is generated such as APIRequest includes the inferred required parameter values.).
With respect to claim 18, Ed-douibi also discloses wherein the one or more instructions, that cause the system to determine the test case dataset, cause the system to determine the test case dataset based on at least one of the specification, data traffic associated with the API, or user input (e.g., Figs. 1-6 and associated text, e.g., p. 184, § VI. Inferring Parameter Values … PR 3 (Complex parameter value inference). A value of a parameter p could be inferred from the response of an operation o if: (1) o is testable; (2) o returns a successful response r; and (3) r.schema contains a property matching p; p. 185, left column, top para., Note that PR 2 and PR 3 stress the API (i.e., they involve sending several requests to the API) [determine the test case dataset based on data traffic associated with the API].).
With respect to claim 19, Ed-douibi also discloses wherein the test object is compatible with (e.g., Figs. 1-6 and associated text, e.g., p. 181, right col., last para., Models conforming to this metamodel are created from REST API definitions, and later used to generate the executable code to test the API; p. 183, § IV., 2nd para., Finally the last step transforms the TestSuite model into executable code (JUnit [framework] in our case); p. 187, § VIII. Code Generation, Since the test case definitions are platform-independent, any programing language or testing tool could be considered; p. 187, § IX, 2nd para., Finally, we used Acceleo to generate the JUnit test cases [test suite].). and Martin-Lopez further teaches each framework in the plurality of different frameworks (e.g., Figs. 1-2 on p. 683 and associated text, e.g., p. 682, right col., last para., The test cases can be instantiated into several frameworks and libraries such as REST Assured and Postman; p. 683, left col., last para., (3) Test case generation. Abstract test cases are instantiated into executable test cases using specific testing frameworks and libraries such as REST Assured.).
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 invention of Ed-douibi with the invention of Martin-Lopez for the same reason set forth above.
With respect to claim 20, Ed-douibi also discloses wherein the plurality of test cases includes a test case associated with an API response (e.g., Figs. 5-6 on p. 188 and associated text, e.g., pp. 186-187, § VII. B. OpenAPI to TestSuite Transformation….GR 1 generates nominal test case definitions which assess that given correct input data, the API operations return a successful response code (i.e., 2xx family of codes) and respect their specification. GR 2 generates faulty test case definitions which assess that given incorrect input data, the API operations return a client error response code (i.e., 4xx family of codes); p. 183, left column, section C. Specification-based API Testing, In specification-based REST API testing, test cases consist of sending requests over HTTP/S and validating that the server responses conform to the specification.).
Prior Art Arguments – Rejections
Applicant’s arguments with respect to the prior art rejections have been fully considered, but are moot in view of the new grounds of rejection presented herein.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Merritt US 10990516 B1 discloses using machine learning models to parse an input API and generate a test suite.
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 STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern.
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 on 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.
/STEPHEN D BERMAN/ Examiner, Art Unit 2192
1 See Applicant’s specification at [0022]
2 See specification at [0032].
Prosecution Insights