DETAILED ACTION
Claims 1-14 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This final office action is in response to the applicant’s response received on 08/07/2026, for the non-final office action mailed on 05/07/2026.
Examiner’s Notes
Examiner has cited particular columns and line numbers, paragraph numbers, or figures in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant, in preparing the responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Arguments
Applicant's arguments filed 08/07/2026 have been fully considered but they are not persuasive.
Applicant argues Tyler doesn’t teach two API specifications associated with a single service for the purpose of compatibility testing, see applicant’s remarks pp. 9-11. Examiner respectfully disagrees as Tyler teaches in [column 3, lines 7-21] “trend towards increased versioning of APIs, as each version of an API may warrant at least partially different sets of functional tests, and increased proliferation of APIs between different services in distributed applications”. That is, versioning of APIs for the same service may lead to compatibility issues and Tyler [column 10, lines 4-25 “three pairs of API servers and respective API models 14 and 16 for APIs exposed by the service”. That is, multiple different APIs for the same service that are to be tested for functionality (functionality test across multiple versions is a test of compatibility, even if not by name). .
Applicant further argues Tyler doesn’t teach processing, by the adapter unit, the second API specification through the interface to generate a second translated API specification, see applicant’s remarks pp. 11-12. Examiner respectfully disagrees as Tyler teaches in [column 10, lines 41-48] transforming API requests which can be done through the different API models taught in Tyler (see Tyler [column 6, lines 46-49], “API models may be expressed or otherwise encoded in a variety of formats. In some embodiments, API models may be a Swagger specification, an Open API specification, or the like”) hence why the reliance on the same disclosure for the first API specification and the second API specification. Tyler also teaches in [column 12, lines 16-40 “In some embodiments, the model parser 36 may be configured to load an API model into program memory and parse the API model to populate program state with a data model of API models of the functional-test generator. Some embodiments may maintain relationships between entities expressed in the API model in the data model of program state, and some embodiments may maintain the identity of different data elements in the data model of program state. Examples include converting a hierarchical serialized data format document into a collection of objects in an object-oriented programming language having attributes corresponding to lower-levels of a hierarchy in the document relative to an entry corresponding to the object. Other examples include converting a hierarchical serialized data format document into a hierarchical arrangement of lists and dictionaries in key-value pairs. In some embodiments, the model parser 36 is configured to detect an API model schema identified in text of the API model and converts different API model schema representations into a unified schema of the functional-test generator 34, for instance, with a different schema converter for different API specifications. In some cases, the resulting data model loaded in program state may be accessible to the parameter-set generator 38, the API-request generator 40, and the response-criteria generator 42” showing the different schema representation being converted into a unified schema for the different API specifications.
Applicant also argues Tyler does not teach generating, by a processing unit, a first set of scenarios for the first API specification based on the first translated API specification and generating, by the processing unit, a second set of scenarios for the second API specification based on the second translated API specification, see applicant’s remarks pp. 13-14. Examine respectfully disagrees as Tyler is generating the different test cases (i.e., scenarios) for the API models (see Tyler [column 16, lines 1-14], “To this end, some embodiments may generate specifications of positive test cases, as indicated by block 80. Some embodiments may test a single positive test case for all of the parameters, and some embodiments may test a plurality of different positive test cases, for instance, across the range, holding each of the parameters other than one constant across the tests. Some embodiments may further generate specifications of positive edge test cases, as indicated by block 82. In some cases, values of parameters for positive edge cases may be determined based upon the API model, for instance, selecting values at (and within) the edges of permitted ranges, selecting values expected to invoke different branches of program flow (like zero, negative values, dates before after the millennium, and the like)”). Applicant further points out to the specification to further explain the objected feature of claim 1. This argument is moot as this is not being claimed. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “the first API specification and the second API specification could be different versions of the same API specification”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Furthermore, applicants argue Tyler doesn’t teach generating, by a test engine, a set of executable tests based on the first set of scenarios, see applicant’s remarks pp. 14. Examiner respectfully disagrees as Tyler teaches in [column 16, lines 27-31] executable code used to conduct testing. Applicant further points out to the specification to further explain the objected feature of claim 1. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “Each one or more executable tests from the set of executable tests is associated with a scenario from the first set of scenarios”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant argues initiating, by the test engine, one or more executable test from the set of executable tests, wherein each executable test from the set of executable tests is associated with a scenario from the first set of scenarios, see applicant’s remarks pp. 15-16. Examiner respectfully disagrees as the functional tests specifications which pertain to each scenario of the API model are inputted to the functional-test specification generator in which a collection of the tests is generated (see Tyler [column 14, lines 56-67], “In some embodiments, the output of modules 38, 40, and 42 may be supplied to a functional test generator 44, which may arrange these outputs in a functional-test specification for a given test. In some embodiments, this may include arranging these different components in a set of labeled data elements corresponding to different parts of the test. In some embodiments, each of a relatively large number of functional tests specifications may then be input into the functional-test specification generator 46, which may arrange the collection of functional-test specifications in a document or other record, like a hierarchical serialized data format encoding suitable for committing to persistent storage”). Applicants also argue with the recitation of a proxy server. Examiner respectfully disagrees as Tyler wasn’t relied upon to teach the proxy server (see Stratton paragraph [0050], “For example, a first test instance could be used to test an API sequence using a first API test server and a second test instance could be used to test an API sequence using a second API test server. In one implementation, a copy or new instance of an existing API interaction sequence can be generated within an account. The context variables can be edited to quickly update the new API interaction sequence instance for an appropriate use case”). In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant argues Stratton does not teach initiating a proxy server based on the second set of scenarios, see applicant’s remarks pp. 17-18. Examiner respectfully disagrees as applicant points out to the specification to further explain the objected feature of claim 1 also Stratton teaches in paragraph [0050], “For example, a first test instance could be used to test an API sequence using a first API test server and a second test instance could be used to test an API sequence using a second API test server. In one implementation, a copy or new instance of an existing API interaction sequence can be generated within an account. The context variables can be edited to quickly update the new API interaction sequence instance for an appropriate use case.” In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “at step 216, the proxy server is initiated based on the second set of scenarios generated by the processing unit”, “is configured to receive the second set of scenarios and the testing request initiated by the test engine”, and “identifies a target scenario (from the second set of scenarios) for each initiated test”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant argues prior art doesn’t teach identifying, by the proxy server, a corresponding target scenario for each test from the one or more initiated tests, based on the second set of scenarios, see applicant’s remarks pp. 18-19. Examiner respectfully disagrees as applicant points out to the specification to further explain the objected feature of claim 1 see Stratton paragraph [0033], “The API usage templating engine 120 of a preferred embodiment functions to define data objects that can be used to construct and execute a templated test. Input obtained through the API usage template interface 110 described above can be used to instruct the construction of resources used in defining test execution. A test is preferably a set of templates based on a sequence of API requests and responses to be made/received with an API service provider”). In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “identifies a target scenario (from the second set of scenarios) for each initiated test” and “a request matcher in the proxy server will see which scenario matches with Test T1”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicants also argue the prior art doesn’t teach generating, by the proxy server, one or more responses for each said corresponding target scenario, see applicant’s remarks pp. 19-20. Examiner respectfully disagrees as applicant points out to the specification to further explain the objected feature of claim 1 see Stratton paragraph [0039], “The current context is determined from context data object that is used to define how variable values are extracted from API requests and/or responses and define initial values. The output of the test template assembler 130 is preferably an API request (or response) that has been updated according to defined templating.” In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “the proxy server generated one or more responses (a success or failure), for each corresponding target scenario identified at step 220” and “generates all possible responses as success or failures”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Furthermore, applicant argues verifying by the test engine, the generated one or more responses for each said corresponding target scenario based on the scenario from the first set of scenarios, said scenario is associated with the initiated one or more tests, see applicant’s remarks pp. 21-22. Examiner respectfully disagrees as applicant points out to the specification to further explain the objected feature of claim 1 see Stratton paragraph [0072], “The method can include detecting a result of an assertion test and executing the notification action. In one exemplary implementation, a user can configure routine API interaction sequences to run every day to verify that API sequences used by an application are still compatible with one or more API service providers. When everything is operating normally, all assertions are verified. If an assertion fails, the assertion failure can result in executing a notification of an administrator so that the issue can be quickly resolved. Additionally or alternatively, the executed notification can be a programmatic notification.” In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “the response received from the proxy server is based on second API specification” and “which is based on the first API specification, will check if there is a delta/change between the expected and actual response at the two levels”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant further argues Elkabany does not teach generating, by the test engine, a set of verification results based on verification of the generated one or more responses for each said corresponding target scenario, see applicant’s remarks pp. 22-25. Examiner respectfully disagrees as the cited prior art is validating data that is sent to see whether it conforms with API specification see Elkabany paragraph [0114-0115], “A client-side output 208 can validate inputs and outputs while running on client 102. Such an output can also make API requests to an API server. Similarly, a server-side output 208 can validate inputs and outputs as well as receive API requests from a client. For example, server-side output 208 can analyze data as it is to be sent from the server and determine whether it conforms with API specification 202. In some embodiments, API analytics engine can verify that data that is to be sent from the server conforms with API specification 202. If data to be sent form the server is nonconforming, an error can be produced instead of sending nonconforming data. Using the principles herein disclosed enables a developer to focus their API development on, for example, API specification 202. Dependent outputs 208 can be automatically generated”). Examiner also respectfully disagrees as applicant points out to the specification to further explain the objected feature of claim 1. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “different versions of the same API specification or different API specifications for a single service”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant also argues Elkabany does not teach generating, by a compatibility report generator, a compatibility report based on at least the set of verification results, see applicant’s remarks pp. 26-27. Examiner respectfully disagrees as Elkabany is producing a compatibility analysis based on the results of the API specification see Elkabany paragraph [0124], “API analytics engine 300 can use the results of API specification and compatibility analyzer 312 to provide developer feedback 314. Developer feedback 314 can be a file (e.g., a text file describing errors, warnings, or summarizing differences), print statements in a command line, comments embedded within API specification 302 (or a copy of API specification 302), etc. In some embodiments, developer feedback 314 can be incorporated into documentation 308n (e.g., changelogs). Developer feedback 314 can include identifying deprecated routes and inserting them into API specification 302 (with comments as appropriate).”) Examiner further respectfully disagrees as applicant points out to the specification to further explain the objected feature of claim 1. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “compares E1 and E5 and generates a success or failure output for test T1”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant also argues Tyler, Stratton and Elkabany rationale for combining, see applicant’s remarks pp. 28-29. Examiner respectfully disagrees as stated below in the office action Examiner did articulate a reasoning with rational underpinning. Tyler, Stratton and Elkabany are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Tyler’s teaching of application program interface (API) functional-test generation and Stratton’s teaching of automating API integration into the API field with Elkabany’s teaching of interface description language for application programming interfaces to incorporate being able to generate results based on tests and provide feedback regarding changes/modification that would or could be done for compatibility purposes amongst API versions. Stratton and Elkabany would not destroy the principal operation of Tyler and the combination of the prior arts relates to aspects of application programming interfaces for testing, verifying and validating the application programming interface configurations. Examiners also respectfully disagree as applicant keeps pointing to the specification, applicant should amend the claim to what applicant is pointing out clarifies the position of the claimed invention. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “test T1 is associated with scenario X from the first set scenarios and expected response E1”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-14 are rejected under 35 U.S.C. 103 as being unpatentable over Tyler et al. (US-PAT-NO: 10,437,712 B1) hereinafter Tyler, in further view of Stratton et al. (US-PGPUB-NO: 2015/0128103 A1) and Elkabany (US-PGPUB-NO: 2017/0337052 A1).
As per claim 1, Tyler teaches a method for testing a compatibility between a first API specification and a second API specification, the method comprising: receiving, at a communication unit, the first API specification and the second API specification (see Tyler [column 6, lines 46-49], “API models may be expressed or otherwise encoded in a variety of formats. In some embodiments, API models may be a Swagger specification, an Open API specification, or the like”), wherein the first API specification and the second API specification are associated with a single service (see Tyler [column 10, lines 4-6], “The illustrated computing environment 10 includes three pairs of API servers and respective API models 14 and 16 for APIs exposed by the service”); processing, by an adapter unit, the first API specification through an interface to generate a first translated API specification (see Tyler [column 10, lines 41-48], “Similarly, API consumer processes 18 may be any of a diverse universe of processes configured to interact with an API. In some embodiments, consumer processes 18 may be configured to write data to server-side storage via the API, read data from server-storage via the API, request that data sent to the API or accessed server-side be transformed in some manner requested by an API request by the server-site processes, or otherwise invoke functionality of the API through API requests”); processing, by the adapter unit, the second API specification through the interface to generate a second translated API specification (see Tyler [column 10, lines 41-48], “Similarly, API consumer processes 18 may be any of a diverse universe of processes configured to interact with an API. In some embodiments, consumer processes 18 may be configured to write data to server-side storage via the API, read data from server-storage via the API, request that data sent to the API or accessed server-side be transformed in some manner requested by an API request by the server-site processes, or otherwise invoke functionality of the API through API requests”); generating, by a processing unit, a first set of scenarios for the first API specification based on the first translated API specification (see Tyler [column 16, lines 1-14], “To this end, some embodiments may generate specifications of positive test cases, as indicated by block 80. Some embodiments may test a single positive test case for all of the parameters, and some embodiments may test a plurality of different positive test cases, for instance, across the range, holding each of the parameters other than one constant across the tests. Some embodiments may further generate specifications of positive edge test cases, as indicated by block 82. In some cases, values of parameters for positive edge cases may be determined based upon the API model, for instance, selecting values at (and within) the edges of permitted ranges, selecting values expected to invoke different branches of program flow (like zero, negative values, dates before after the millennium, and the like)”); generating, by the processing unit, a second set of scenarios for the second API specification based on the second translated API specification (see Tyler [column 16, lines 1-14], “To this end, some embodiments may generate specifications of positive test cases, as indicated by block 80. Some embodiments may test a single positive test case for all of the parameters, and some embodiments may test a plurality of different positive test cases, for instance, across the range, holding each of the parameters other than one constant across the tests. Some embodiments may further generate specifications of positive edge test cases, as indicated by block 82. In some cases, values of parameters for positive edge cases may be determined based upon the API model, for instance, selecting values at (and within) the edges of permitted ranges, selecting values expected to invoke different branches of program flow (like zero, negative values, dates before after the millennium, and the like)”); generating, by a test engine, a set of executable tests based on the first set of scenarios (see Tyler [column 16, lines 27-31], “Some embodiments may further generate specifications of security test cases, as indicated by block 88, for instance, by assigning values to the current selected parameter that are configured to cause a buffer overflow or include executable code”); initiating, by the test engine, one or more executable tests from the set of executable tests, wherein each executable test from the set of executable tests is associated with a scenario from the first set of scenarios (see Tyler [column 14, lines 56-67], “In some embodiments, the output of modules 38, 40, and 42 may be supplied to a functional test generator 44, which may arrange these outputs in a functional-test specification for a given test. In some embodiments, this may include arranging these different components in a set of labeled data elements corresponding to different parts of the test. In some embodiments, each of a relatively large number of functional tests specifications may then be input into the functional-test specification generator 46, which may arrange the collection of functional-test specifications in a document or other record, like a hierarchical serialized data format encoding suitable for committing to persistent storage”).
Tyler does not explicitly teach initiating a proxy server based on the second set of scenarios; identifying, by the proxy server, a corresponding target scenario for each test from the one or more initiated tests, based on the second set of scenarios; generating, by the proxy server, one or more responses for each said corresponding target scenario; verifying, by the test engine, the generated one or more responses for each said corresponding target scenario based on a scenario from the first set of scenarios, said scenario is associated with the initiated one or more tests. However, Stratton teaches initiating a proxy server based on the second set of scenarios (see Stratton paragraph [0050], “For example, a first test instance could be used to test an API sequence using a first API test server and a second test instance could be used to test an API sequence using a second API test server. In one implementation, a copy or new instance of an existing API interaction sequence can be generated within an account. The context variables can be edited to quickly update the new API interaction sequence instance for an appropriate use case”); identifying, by the proxy server, a corresponding target scenario for each test from the one or more initiated tests, based on the second set of scenarios (see Stratton paragraph [0033], “The API usage templating engine 120 of a preferred embodiment functions to define data objects that can be used to construct and execute a templated test. Input obtained through the API usage template interface 110 described above can be used to instruct the construction of resources used in defining test execution. A test is preferably a set of templates based on a sequence of API requests and responses to be made/received with an API service provider”); generating, by the proxy server [108], one or more responses for each said corresponding target scenario (see Stratton paragraph [0039], “The current context is determined from context data object that is used to define how variable values are extracted from API requests and/or responses and define initial values. The output of the test template assembler 130 is preferably an API request (or response) that has been updated according to defined templating”); verifying, by the test engine [110], the generated one or more responses for each said corresponding target scenario based on a scenario from the first set of scenarios, said scenario is associated with the initiated one or more tests (see Stratton paragraph [0072], “The method can include detecting a result of an assertion test and executing the notification action. In one exemplary implementation, a user can configure routine API interaction sequences to run every day to verify that API sequences used by an application are still compatible with one or more API service providers. When everything is operating normally, all assertions are verified. If an assertion fails, the assertion failure can result in executing a notification of an administrator so that the issue can be quickly resolved. Additionally or alternatively, the executed notification can be a programmatic notification”).
Tyler and Stratton are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Tyler’s teaching of application program interface (API) functional-test generation with Stratton’s teaching of automating API integration into the API field to incorporate being able to test and verify API requests and responses to see whether the API integration is compatible.
Tyler modified with Stratton do not explicitly teach receiving, at a communication unit, the first API specification and the second API specification, wherein the first API specification and the second API specification are associated to a single service; generating, by the test engine, a set of verification results based on verification of the generated one or more responses for each said corresponding target scenario; and generating, by a compatibility report generator, a compatibility report based on at least the set of verification results. However, Elkabany teaches receiving, at a communication unit, the first API specification and the second API specification, wherein the first API specification and the second API specification are associated to a single service (see Elkabany paragraph [0116], “FIG. 3 shows an exemplary logical component diagram 300 for comparing API specification 302 and past API specification 303 to provide developer feedback” showing the API specification are different versions of each other servicing the same function/service); generating, by the test engine, a set of verification results based on verification of the generated one or more responses for each said corresponding target scenario (see Elkabany paragraph [0114-0115], “A client-side output 208 can validate inputs and outputs while running on client 102. Such an output can also make API requests to an API server. Similarly, a server-side output 208 can validate inputs and outputs as well as receive API requests from a client. For example, server-side output 208 can analyze data as it is to be sent from the server and determine whether it conforms with API specification 202. In some embodiments, API analytics engine can verify that data that is to be sent from the server conforms with API specification 202. If data to be sent form the server is nonconforming, an error can be produced instead of sending nonconforming data. Using the principles herein disclosed enables a developer to focus their API development on, for example, API specification 202. Dependent outputs 208 can be automatically generated”); and generating, by a compatibility report generator, a compatibility report based on at least the set of verification results (see Elkabany paragraph [0124], “API analytics engine 300 can use the results of API specification and compatibility analyzer 312 to provide developer feedback 314. Developer feedback 314 can be a file (e.g., a text file describing errors, warnings, or summarizing differences), print statements in a command line, comments embedded within API specification 302 (or a copy of API specification 302), etc. In some embodiments, developer feedback 314 can be incorporated into documentation 308n (e.g., changelogs). Developer feedback 314 can include identifying deprecated routes and inserting them into API specification 302 (with comments as appropriate)”).
Tyler, Stratton and Elkabany are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Tyler’s teaching of application program interface (API) functional-test generation and Stratton’s teaching of automating API integration into the API field with Elkabany’s teaching of interface description language for application programming interfaces to incorporate being able to generate results based on tests and provide feedback regarding changes/modification that would or could be done for compatibility purposes amongst API versions.
As per claim 2, Tyler modified with Stratton and Elkabany teaches wherein the compatibility report comprises at least one of a list of compatible changes, a list of incompatible changes, a list of structural changes and a list of unverified scenarios (see Elkabany paragraph [0116], “FIG. 3 shows an exemplary logical component diagram 300 for comparing API specification 302 and past API specification 303 to provide developer feedback. For example, past API specification 303 can include past minor versions of an API (e.g., v2.3 when specification 302 is at v2.4) and/or past major versions of an API (e.g., v1.0 when API specification 302 is at v2.0). In some environments, minor version increases should retain compatibility with programs designed for a previous version within the same major version family (e.g., 1.x). It can also be desirable to retain capability with prior major versions as well. Thus, it is important to determine differences between the versions and whether programs written to access a previous version of the API might result in errors. In some embodiments, a version number can have a first part designating the major version and a second part designating a minor version; for example: major.minor or 2.3. The principles disclosed herein can be applied to other numbering conventions as known in the art”).
As per claim 3, Tyler modified with Stratton and Elkabany teaches wherein the first API specification and the second API specification is one of a different version of a same API specification standard and different API specification standards (see Elkabany paragraph [0116], “FIG. 3 shows an exemplary logical component diagram 300 for comparing API specification 302 and past API specification 303 to provide developer feedback. For example, past API specification 303 can include past minor versions of an API (e.g., v2.3 when specification 302 is at v2.4) and/or past major versions of an API (e.g., v1.0 when API specification 302 is at v2.0). In some environments, minor version increases should retain compatibility with programs designed for a previous version within the same major version family (e.g., 1.x). It can also be desirable to retain capability with prior major versions as well. Thus, it is important to determine differences between the versions and whether programs written to access a previous version of the API might result in errors. In some embodiments, a version number can have a first part designating the major version and a second part designating a minor version; for example: major.minor or 2.3. The principles disclosed herein can be applied to other numbering conventions as known in the art”).
As per claim 4, Tyler modified with Stratton and Elkabany teaches wherein the one or more the set of executable tests are generated dynamically based on the one or more scenarios generated for the first API specification (see Stratton paragraph [0042], “The method is preferably configured such that API testing is generalized and flexible to be applied to a wide variety of APIs as used by a variety of different applications/services. In an exemplary case of usage, a user can create an account on an API service platform (i.e., the method implementer), run API interactions through the API service platform, configure templates for a sequence of API interactions (which can be based on previously API interactions captured by the API service platform), and then execute a sequence of API interactions based on the templates. The executed sequence of API interactions can be dynamically set based on initialization, intermediary results of previous interactions in the API interaction sequence, scripting and integration with additional services, or other suitable factors”).
As per claim 5, Tyler modified with Stratton and Elkabany teaches wherein the first translated API specification and the second translated API specification is in a common standardized format (see Tyler [column 6, lines 46-49], “API models may be expressed or otherwise encoded in a variety of formats. In some embodiments, API models may be a Swagger specification, an Open API specification, or the like”).
As per claim 6, Tyler modified with Stratton and Elkabany teaches wherein the method is implemented at least one of a specification authoring stage, a specification change review stage, a pre-production stage and a production stage (see Elkabany paragraph [0139], “Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims”).
As per claim 7, Tyler modified with Stratton and Elkabany teaches wherein the compatibility between the first API specification and the second API specification is one of a forward compatibility, a backward compatibility and a full compatibility (see Elkabany paragraph [0121], “There are certain modifications to an API that are backwards compatible, i.e., programs designed for a previous version of the API will not break when attempting to connect to the new version of the API. An example of a backwards compatible change includes adding a new route. Another example includes changing the name of a struct, union, or alias”).
As per claim 8-13, these are the system claims to method claims 1-6, respectively. Therefore, they are rejected for the same reasons as above.
As per claim 14, this is the non-transitory computer-readable medium comprising computer-executable instruction, when executed by a computing system, cause the computing system to perform a method for testing a compatibility between a first API specification and a second API specification (see Elkabany paragraph [0134], “Any of the steps, operations, functions, or processes described herein may be performed or implemented by a combination of hardware and software modules, alone or in combination with other devices. In an embodiment, a software module can be software that resides in memory of a client device and/or one or more servers of a content management system and perform one or more functions when a processor executes the software associated with the module. The memory can be a non-transitory computer-readable medium”) claim to method claim 1. Therefore, it is rejected for the same reasons as above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Battiato et al. (US-PGPUB-NO: 2023/0089336 A1) teaches automated generation of load tests for API testing.
Dolby et al. (US-PGPUB-NO: 2018/0357154 A1) teaches automatically running tests against web APIs based on specifications.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LENIN PAULINO whose telephone number is (571)270-1734. The examiner can normally be reached Week 1: Mon-Thu 7:30am - 5:00pm Week 2: Mon-Thu 7:30am - 5:00pm and Fri 7:30am - 4:00pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at (571) 272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/LENIN PAULINO/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights