DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to Applicant’s Amendment filed on 6/19/2026.
Claims 1-20 are presented for examination. Claims 1, 7, 9, 17 and 19-20 have been amended.
Applicant’s amendments to the claims have overcome claim objections and 101 rejection set forth in the non-Final Office Action mailed 3/25/2026.
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 entirely 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 Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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, 4, 7-10, 14-15, 17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sagar (US 11734265 B1) in view of Leach et al. (US 20180165083 A1, hereafter Leach).
Regarding to claim 1, Sagar discloses: A computer-implemented method (see lines 60-62 of col. 4 and claim 1; “the process may be performed by one or more processors of the GraphQL server 202 executing code comprising the components therein” and “A method for API management by a GraphQL server”) comprising:
executing a first query associated with at least one operation of a computer function that utilizes an application programming interface (API); determining whether the first query validates to a schema for the at least one operation of the computer function, for a version of the API that is higher than a version of the API that the computer function currently calls (see lines 55-8 of cols. 2-3; “receives the GraphQL API query requests 112 (also referred to as requests 112) from the clients 104. The requests 112 may comprise query payloads that specify an operation name, the variables and fields whose values are to be retrieved (e.g., an application/JSON content type and a JSON-encoded body). Once received, the GraphQL API gateway 116 sends the request 112 to the validation service 118. The validation service 118 validates the request 112 by retrieving the schema defining the GraphQL API from the schema store 120 and verifying the syntactic structure and field names in the request 112 against the schema”. Also see lines 36-50 of col. 2 and lines 26-40 of col. 5; “accepts GraphQL API query requests 112 from the clients 104, aggregates the various services required to fulfill the queries using the data sources 106, and returns a response 114 to the requesting client 104 … The schema store 120 stores the schemas that are associated with the GraphQL APIs. The GraphQL schemas are the API specification for a GraphQL API that define the operations, ata types and fields (similar to API specifications used by RAML and OAS for REST APIs)” and “when a commit is made to an API specification or a new version of the API specification is published”); and
responsive to determining that the first query validates to the schema for the higher version of the API, executing the computer function to subsequently have the computer function call the higher version of the API (see lines 66-4 of cols. 2-3; “Once the query payload is validated, the validation service 118 calls the resolution service 122, which uses the field resolvers 124 associated with the fields in the query to fetch the data from the corresponding data source 106, combines the retrieved data as defined in the schema, and returns a response 114 to the GraphQL API gateway 116”. Also see lines 26-40 of col. 5; “when a commit is made to an API specification or a new version of the API specification is published”).
Sagar does not disclose: responsive to determining that the first query validates to the schema for the higher version of the API, updating metadata for the computer function to subsequently have the computer function call the higher version of the API.
However, Leach discloses: executing a first query associated with at least one operation of a computer function that utilizes an object, to determine whether the first query validates to a schema for the at least one operation of the computer function, for a version of the object that is higher than a version of the object that the computer function currently utilizes; and responsive to the first query validating to the schema, updating metadata for the computer function to subsequently have the operation utilizes the higher version of the object (see [0030]-[0031]; “updates a relation (such as a table in the relational database context) that identifies the metadata versions that are valid for each version of the client software 114 with the newer metadata 130 and an indication of which versions of the client software 114 are compatible with the newer metadata 130”, “The schema for the use of the metadata (i.e., metadata 120 and newer metadata 130) is the same with respect to the central repository 128 and the local repository 118”. Note: the relation and indication discussed at [0030]-[0031] are considered as claimed metadata to be updated instead of object metadata discussed at [0030]-[0031]. Also see [0035]; “When newer metadata 130 is introduced into the query, a different analysis is taken … the new metadata 130 will be determined to be compatible because it is within the range of all the versions of the client software 114. Here, version 1 is queried against the newer metadata 130. The results (indicated by the bullet point “Results in range”) shows that the metadata is in range, and is compatible with version 1 of the client software”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify API version compatibility validation from Sagar by including updating version compatibility information in response to a version compatibility validation process from Leach, and thus the combination of Sagar and Leach would disclose the missing limitations from Sagar, since it would provide a update-to-date relation table to indicate compatible pair (see [0030] from Leach; “The update management service 102 updates a relation (such as a table in the relational database context) that identifies the metadata versions that are valid for each version of the client software 114 with the newer metadata 130 and an indication of which versions of the client software 114 are compatible with the newer metadata 130”).
Regarding to Claim 4, the rejection of Claim 1 is incorporated and further the combination of Sagar and Leach discloses: executing a second query associated with the at least one operation of the computer function that utilizes the API, to determine whether the second query validates to the schema (see lines 55-8 of cols. 2-3; “receives the GraphQL API query requests 112 (also referred to as requests 112) from the clients 104 … Once received, the GraphQL API gateway 116 sends the request 112 to the validation service 118. The validation service 118 validates the request 112 by retrieving the schema defining the GraphQL API from the schema store 120 and verifying the syntactic structure and field names in the request 112 against the schema”. Note: it is understood that the features described by lines 55-8 of cols. 2-3 can be performed multiple times for different received API requests); and
responsive to the second query not validating to the schema, executing a remediation action (see lines 30-58 of col. 7 from Sagar; “the request validation service 218 inspects the payload of the API request 112 and checks if the operation(s) are valid as per the schema 121 … some fields names in the request payload don't match the schema 121 … The request validation service 218 then updates the payload of the API request 112 to add an ‘alias’ for the fields whose names have been updated by using new field values from field mapper 208 … The request validation service 218 passes the updated API request to the resolution service 122 … the field resolver 224 is called on the new field name and it is able to fetch the corresponding field name from the data source 106”).
Regarding to Claim 7, the rejection of Claim 4 is incorporated and further the combination of Sagar and Leach discloses: wherein the remediation action comprises executing the second query for a version of the API that is between the version currently called and a latest version (see lines 30-32 of col. 5 and lines 30-58 of col. 7 from Sagar; “when a commit is made to an API specification or a new version of the API specification is published” and “the request validation service 218 inspects the payload of the API request 112 and checks if the operation(s) are valid as per the schema 121 … some fields names in the request payload don't match the schema 121 … The request validation service 218 then updates the payload of the API request 112 to add an ‘alias’ for the fields whose names have been updated by using new field values from field mapper 208 … The request validation service 218 passes the updated API request to the resolution service 122 … the field resolver 224 is called on the new field name and it is able to fetch the corresponding field name from the data source 106”. Note: it is understood that the new version discussed at lines 30-32 of col. 5 is a version between the version currently called and the latest version).
Regarding to Claim 8, the rejection of Claim 1 is incorporated and further the combination of Sagar and Leach discloses: wherein the metadata comprises a runtime table storing API versions for at least one computer function (see [0030] from Leach; “updates a relation (such as a table in the relational database context) that identifies the metadata versions that are valid for each version of the client software 114 with the newer metadata 130 and an indication of which versions of the client software 114 are compatible with the newer metadata 130”. Note: the relation table from Leach itself alone is not a table storing API versions information; however, after combining such feature related to updating relation table into the system of Sagar, the new combination system would include a relation table storing API versions information).
Regarding to Claim 9, the rejection of Claim 1 is incorporated and further the combination of Sagar and Leach discloses: wherein the computer function operates within a same computing environment as a process executing the first query (see Fig. 1, lines 66-4 of cols. 2-3 from Sagar; “Once the query payload is validated, the validation service 118 calls the resolution service 122, which uses the field resolvers 124 associated with the fields in the query to fetch the data from the corresponding data source 106, combines the retrieved data as defined in the schema, and returns a response 114 to the GraphQL API gateway 116”).
Regarding to Claim 10, the rejection of Claim 9 is incorporated and further the combination of Sagar and Leach discloses: wherein the process executing the first query is triggered by an event (see lines 55-8 of cols. 2-3 from Sagar; “receives the GraphQL API query requests 112 (also referred to as requests 112) from the clients 104 … Once received, the GraphQL API gateway 116 sends the request 112 to the validation service 118. The validation service 118 validates the request 112 by retrieving the schema defining the GraphQL API from the schema store 120”).
Regarding to Claim 14, the rejection of Claim 1 is incorporated and further the combination of Sagar and Leach discloses: wherein the first query performs a static validation without running the computer function in its environment (see lines 13-18 of col. 1, lines 55-8 of cols. 2-3 from Sagar; “GraphQL includes a type system, query language and execution semantics, static validation, and type introspection” and “Once received, the GraphQL API gateway 116 sends the request 112 to the validation service 118. The validation service 118 validates the request 112 by retrieving the schema defining the GraphQL API from the schema store 120 … Once the query payload is validated, the validation service 118 calls the resolution service 122, which uses the field resolvers 124 associated with the fields in the query to fetch the data from the corresponding data source 106”. The execution or running the computer function is performed after the validation, and thus query related to the static validation cause by GrpahQL is performed without running the computer function in its environment).
Regarding to Claim 15, the rejection of Claim 14 is incorporated and further the combination of Sagar and Leach discloses: wherein the first query comprises executing a GraphQL routine (see lines 13-18 of col. 1, lines 55-60 of col. 2 from Sagar; “GraphQL includes a type system, query language and execution semantics, static validation, and type introspection” and “receives the GraphQL API query requests 112 (also referred to as requests 112) from the clients 104”).
Regarding to Claim 17, Sagar discloses: A system comprising:
at least one processor; and at least one memory, the at least one memory comprising processor executable instructions that, when executed by the at least one processor (see Fig. 4A, lines 49-56 of col. 9; “an electronic device 400 according to some example implementations … machine-readable media 426 having stored therein software 428 (which includes instructions executable by the set of one or more processor(s) 422)”), cause the system to:
execute a query associated with at least one operation of a computer function that utilizes an application programming interface (API), to determine whether the query validates to a schema for the at least one operation of the computer function, for a version of the API that is higher than a version of the API that the computer function currently calls (see lines 55-8 of cols. 2-3; “receives the GraphQL API query requests 112 (also referred to as requests 112) from the clients 104. The requests 112 may comprise query payloads that specify an operation name, the variables and fields whose values are to be retrieved (e.g., an application/JSON content type and a JSON-encoded body). Once received, the GraphQL API gateway 116 sends the request 112 to the validation service 118. The validation service 118 validates the request 112 by retrieving the schema defining the GraphQL API from the schema store 120 and verifying the syntactic structure and field names in the request 112 against the schema”. Also see lines 36-50 of col. 2 and lines 26-40 of col. 5; “accepts GraphQL API query requests 112 from the clients 104, aggregates the various services required to fulfill the queries using the data sources 106, and returns a response 114 to the requesting client 104 … The schema store 120 stores the schemas that are associated with the GraphQL APIs. The GraphQL schemas are the API specification for a GraphQL API that define the operations, ata types and fields (similar to API specifications used by RAML and OAS for REST APIs)” and “when a commit is made to an API specification or a new version of the API specification is published”);
responsive to the query validating to the schema, executing the computer function to subsequently have the computer function call the higher version of the API (see lines 66-4 of cols. 2-3; “Once the query payload is validated, the validation service 118 calls the resolution service 122, which uses the field resolvers 124 associated with the fields in the query to fetch the data from the corresponding data source 106, combines the retrieved data as defined in the schema, and returns a response 114 to the GraphQL API gateway 116”); and
responsive to the query not validating to the schema, execute a remediation action (see lines 30-58 of col. 7 from Sagar; “the request validation service 218 inspects the payload of the API request 112 and checks if the operation(s) are valid as per the schema 121 … some fields names in the request payload don't match the schema 121 … The request validation service 218 then updates the payload of the API request 112 to add an ‘alias’ for the fields whose names have been updated by using new field values from field mapper 208 … The request validation service 218 passes the updated API request to the resolution service 122 … the field resolver 224 is called on the new field name and it is able to fetch the corresponding field name from the data source 106”).
Sagar does not disclose: responsive to the query validating to the schema, update metadata for the computer function to subsequently have the computer function call the higher version of the API.
However, Leach discloses: execute a query associated with at least one operation of a computer function that utilizes an object, to determine whether the query validates to a schema for the at least one operation of the computer function, for a version of the object that is higher than a version of the object that the computer function currently utilizes; and responsive to the query validating to the schema, update metadata for the computer function to subsequently have the operation utilizes the higher version of the object (see [0030]-[0031]; “updates a relation (such as a table in the relational database context) that identifies the metadata versions that are valid for each version of the client software 114 with the newer metadata 130 and an indication of which versions of the client software 114 are compatible with the newer metadata 130”, “The schema for the use of the metadata (i.e., metadata 120 and newer metadata 130) is the same with respect to the central repository 128 and the local repository 118”. Note: the relation and indication discussed at [0030]-[0031] are considered as claimed metadata to be updated instead of object metadata discussed at [0030]-[0031]. Also see [0035]; “When newer metadata 130 is introduced into the query, a different analysis is taken … the new metadata 130 will be determined to be compatible because it is within the range of all the versions of the client software 114. Here, version 1 is queried against the newer metadata 130. The results (indicated by the bullet point “Results in range”) shows that the metadata is in range, and is compatible with version 1 of the client software”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify API version compatibility validation from Sagar by including updating version compatibility information in response to a version compatibility validation process from Leach, and thus the combination of Sagar and Leach would disclose the missing limitations from Sagar, since it would provide a update-to-date relation table to indicate compatible pair (see [0030] from Leach; “The update management service 102 updates a relation (such as a table in the relational database context) that identifies the metadata versions that are valid for each version of the client software 114 with the newer metadata 130 and an indication of which versions of the client software 114 are compatible with the newer metadata 130”).
Regarding to Claim 19, Claim 19 is a system claim corresponds to method Claim 7 and is rejected for the same reason set forth in the rejection of Claim 7 above.
Regarding to Claim 20, Claim 20 is a product claim corresponds to system Claim 17 and is rejected for the same reason set forth in the rejection of Claim 17 above.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Sagar (US 11734265 B1) in view of Leach et al. (US 20180165083 A1, hereafter Leach) and further in view of Crisan et al. (US 20220116480 A1, hereafter Crisan).
Regarding to Claim 2, the rejection of Claim 1 is incorporated, the combination of Sagar and Leach does not disclose: wherein the higher version of the API is a next version compared to the version of the API that the computer function currently calls.
However, Crisan discloses: wherein the higher version of the API is a next version compared to the version of the API that the computer function currently calls (see [0007], [0076]; “Each adapter can thereby be configured to transform requests and/or responses between one API version and an immediately preceding or succeeding API version” and “schema validation: to validate requests and responses according to the API definition”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the publication of new version of API from the combination of Sagar and Leach by including publication of a succeeding API version from Crisan, and thus the combination of Sagar, Leach and Crisan would disclose the missing limitations from the combination of Sagar and Leach, since a succeeding version is one of the many well-known understood new versions (note: both of Sagar and Crisan would perform schema validation for the APIs in different versions, Sagar only discusses new version of API is provided but Crisan specifies such new version can be a succeeding or next new version of the API).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Sagar (US 11734265 B1) in view of Leach et al. (US 20180165083 A1, hereafter Leach) and further in view of Cohen et al. (US 20050149543 A1, hereafter Cohen).
Regarding to Claim 3, the rejection of Claim 1 is incorporated, the combination of Sagar and Leach does not disclose: wherein the higher version of the API is a latest version.
However, Cohen discloses: wherein the higher version of the API is a latest version (see [0097] and [0106]; “Schema Level Data Validation: the API request message payload 172 is validated with respect to an underlying schema specific to the API message payload” and “a latest version of an API adopted by the commerce server 12”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the publication of new version of API from the combination of Sagar and Leach by including publication of a latest API version from Cohen, and thus the combination of Sagar, Leach and Cohen would disclose the missing limitations from the combination of Sagar and Leach, since a latest version is one of the many well-known understood new versions (note: both of Sagar and Cohen would perform schema validation for the APIs in different versions, Sagar only discusses new version of API is provided but Cohen specifies such new version can be a latest version of the API).
Claims 5-6, 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sagar (US 11734265 B1) in view of Leach et al. (US 20180165083 A1, hereafter Leach) and further in view of Cohen (US 20100115585 A1).
Regarding to Claim 5, the rejection of Claim 4 is incorporated, the combination of Sagar and Leach does not disclose: wherein the remediation action comprises providing an indication that the computer function cannot be run at runtime.
However, Cohen discloses: wherein the remediation action comprises providing an indication that the computer function cannot be run at runtime (see Fig. 3, [0027]; “If the proxy API is valid, execution continues with S340, otherwise, at S335 the proxy API is blocked (i.e., the API call is not relayed to the engine 220). In accordance with another embodiment, the script in proxy API's payload can be modified to correct security breaches” The remediation actions in response to an invalidated API includes 1. blocking the invalidated API to make the corresponding function associated with the invalidated API cannot be run or performed OR 2. modifying payload of the invalidated API. Also see [0018]; “receives the proxy API call and determines if the call is potentially harmful using a set of validation rules. For example, if the third party module 230 tries to access a restricted network resource. In accordance with an embodiment of the invention only validated proxy API calls are sent to the sand-box engine 220”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the handling operations of invalidated API request from the combination of Sagar and Leach by including either blocking the invalidated API or modifying payload of the invalidated API from Cohen, and thus the combination of Sagar, Leach and Cohen would disclose the missing limitations from the combination of Sagar and Leach, since it would provide multiple different remediation actions in response to invalidated API request (see [0027] from Cohen).
Regarding to Claim 6, the rejection of Claim 5 is incorporated and further the combination of Sagar, Leach and Cohen discloses: wherein flagging the computer function for deprecation comprises one or more of sending a notification to a developer or owner of the computer function, or disabling the computer function (see [0027] from Cohen; “If the proxy API is valid, execution continues with S340, otherwise, at S335 the proxy API is blocked (i.e., the API call is not relayed to the engine 220)”. Blocking the API would also cause disabling the function corresponding to the API).
Regarding to Claim 16, the rejection of Claim 1 is incorporated, the combination of Sagar and Leach does not disclose: wherein the first query comprises operating the computer function within a test environment.
However, Cohen discloses: wherein the first query comprises operating the computer function within a test environment (see [0008] and [0028]; “generating an engine API call including at least the payload parameter; validating the engine API call; and executing the payload parameter if the engine API call is validated” and “If the engine API is determined to be valid, execution continues with S370 where the payload's content (or script) is executed by the sand-box engine 220”. Note: it is understood to one with ordinary skill in the art that a sandbox indicates it is a test environment isolated from other execution environment, and thus the validated API is executed by the sand-box engine 220 discussed at [0028] indicates the corresponding function associated with the validated API is executed within a sandbox or test environment).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the execution of a validated API request from the combination of Sagar and Leach by including executing a validated API request within a sandbox environment, and thus the combination of Sagar, Leach and Cohen would disclose the missing limitations from the combination of Sagar and Leach, since it would provide a secure mechanism for executing API (see [0009] from Cohen).
Regarding to Claim 18, Claim 18 is a system claim corresponds to method Claim 5 and is rejected for the same reason set forth in the rejection of Claim 5 above.
Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Sagar (US 11734265 B1) in view of Leach et al. (US 20180165083 A1, hereafter Leach) and further in view of Danielsson et al. (US 20190384650 A1, hereafter Danielsson).
Regarding to Claim 11, the rejection of Claim 10 is incorporated, the combination of Sagar and Leach does not disclose: wherein the event is associated with a deprecation of the API.
However, Danielsson discloses: wherein the event to trigger querying a validation of a API is associated with a deprecation of the API (see [0037]; “The one or more rules can be associated with versioning, visibility, deprecation, and the like. The compliance module 119 can ensure that all APIs (or API updates) are verified/validated/approved for implementation (e.g., API implementation via the implementation device 116, etc.) and adhere to the one or more rules (e.g., policies, etc.). The compliance module 119, based on the one or more rules can determine an operable status (e.g., operable index, operable value, etc.) of an API and/or an API update”. Also see [0041]-[0042]; “determine an operable status of an API and/or an API update based on a deprecation rule associated with the API and/or the API update. The compliance module 119 can determine/verify a deprecation rule associated with an API and/or an API update based on information received with the API and/or an API update (e.g., an API specification, etc.). The compliance module 119, based on a deprecation rule, can determine portions of an API and/or an API update that have removed, modified, or the like in accordance to and/or in violation of one or more settings (e.g., rules, attributes, deprecation policies, etc.), such as a determined time period … The API management device 104, based on the operable status of an API and/or an API update, can allow or deny a request from a client device (e.g., the client device 102) or any other device for implementation of an API and/or an API update”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the publication of new version of API from the combination of Sagar and Leach by including generating new version of API due to a deprecation rule of the API from Danielsson, and thus the combination of Sagar, Leach and Danielsson would disclose the missing limitations from the combination of Sagar and Leach, since deprecation is well-known and understood mechanism to cause the change of API to generate new version of API (see [0041] from Danielsson).
Regarding to Claim 12, the rejection of Claim 11 is incorporated and further the combination of Sagar, Leach and Danielsson discloses: wherein the event corresponds to a period of time following the deprecation of the API (see [0041] from Danielsson; “The compliance module 119, based on a deprecation rule, can determine portions of an API and/or an API update that have removed, modified, or the like in accordance to and/or in violation of one or more settings (e.g., rules, attributes, deprecation policies, etc.), such as a determined time period”).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Sagar (US 11734265 B1) in view of Leach et al. (US 20180165083 A1, hereafter Leach) and further in view of Rajagopalan et al. (US 20180039567 A1, hereafter Rajagopalan).
Regarding to Claim 13, the rejection of Claim 10 is incorporated and further, the combination of Sagar and Leach does not disclose: wherein the event comprises failure of one of a plurality of computer functions that utilize the API to trigger a batch execution of a process comprising the first query.
However, Rajagopalan discloses: wherein the event comprises failure of one of a plurality of computer functions that utilize the API to trigger a batch execution of a process comprising the first query (see [0003], [0087]; “wherein the application program interface call subgraphs are ordered based on respective failure impact values of the application program interface call subgraphs on a functionality of the microservices-based application … generation of at least one failure scenario for an application program interface call subgraph of the subset of the application program interface call subgraphs; and, using the at least one failure scenario, test of the application program interface call subgraph” and “Test execution component 208 can inject one or more transient failures between the call from API “A” to API “B” to test API “A” for bounded retry pattern”. Failure of corresponding function that utilizes the API to trigger another around of retrying the corresponding function including query operation of validating the corresponding API. Also see [0033] and [0073]; “A resiliency testing system injects faults … a microservice making an API call, failures in a target microservice or the network manifests in the form of, e.g., delayed responses, error responses (e.g., HTTP 404, HTTP 503), invalid responses, connection timeouts, a failure to establish a connection, etc” and “test execution component 208 can automatically perform resiliency testing on API call subgraphs … Resiliency testing performed by test execution component 208 can include in a non-limiting example, timeout pattern tests, bounded retry pattern tests, circuit breaker pattern tests, bulkhead pattern tests, or any other suitable resiliency test for microservices of a microservice-based application. Test execution component 208 validate correct implementation of these design patterns in a given microservice-based application”)
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the validation of API request from the combination of Sagar and Leach by including validation operation of API in response to fault injection from Rajagopalan, and thus the combination of Sagar, Leach and Rajagopalan would disclose the missing limitations from the combination of Sagar and Leach, since it would provide improved performance of automated resiliency testing systems that provides for more efficient usage of resiliency test processing resources in a limited available time (see [0036] from Rajagopalan).
Response to Arguments
Applicant’s arguments, filed 6/19/2026, with respect to rejections of claims 1-20 under 35 U.S.C. 103 have been full considered but they are not persuasive.
Applicant’s arguments at pages 1-4 are summarized as the following:
For the independent claims, Applicant argued that “the mechanism used by Sager involves reactively modifying schemas and requests when data source changes occur to provide field-level changes within a single API version (e.g., by renaming fields). In contrast, the present application describes and claims a process that address version-level compatibility between different API versions with validation of entire operations used by the computer functions. Moreover, in further contrast to Sager, the present application proactively tests compatibility with a higher version, which may be done to avoid validating each individual function at each runtime with the associated performance hit. Furthermore, Sager triggers updates based on the detected schema changes in the data source whereas the present claims trigger use of higher versions of API (e.g., an update) after a successful validation of a query against the schema” (see page 3 from the Remarks).
For the independent claims, Applicant argued that “Leach, however, focuses on metadata compatibility for software version. For example, as cited by the Examiner. Leach updates a relational table to update metadata for different versions of client software. This is not using metadata to have a function use a different version of an API as claimed but instead merely checks that a new version of software is compatible with certain metadata” (see 2nd paragraph and 3rd paragraph of page 4 from the Remarks).
The examiner respectively disagrees.
First of all, Applicant is suggested to review lines 26-40 of col. 5 from Sager (particularly, the description of “when a commit is made to an API specification or a new version of the API specification is published”. According to these descriptions, the “data source fields change” mentioned by Applicant is caused by “a new version of the API specification”, i.e., a new or higher version of API. Such feature is same as the claimed invention. If Applicant wants to argue that a new version of the API specification does not necessary to mean a new version of API, then Applicant is suggested to provide evidence from Applicant’s specification to support that the claimed invention is about a new version of API specification does not result a new version of API. After providing such evidence, Applicant is suggested to amend the claims to include similar language to exclude the interpretation about new version of API specification means a new version of API from the claims.
For the issues related to “field-level changes”, “validation of entire operations”, “avoid validating each individual function”, Applicant is suggested to point out which limitations from the independent claims require the claimed invention only validating entire operations without validating “fields-level changes” or “individual function”. The independent claims now “validates to a schema for the at least one operation of the computer function”. The language of “a schema for the at least one operation” can be represented by either one of “fields-level” or “individual function”. For the issue related to “trigger use of higher versions of API (e.g., an update) after a successful validation of a query against the schema”, as explained above, the schema or data source fields change at Sager is caused by publication of new version of API specification, i.e., a new/higher version of API. If what Applicant tried to argue is about the claimed invention does not need to perform the validation repeatedly later once there is a new API request/call/query, then Applicant is suggested to 1. review the language used at claim 4 since claim 4 does include “a second query” and such query would cause “to determine whether the second query validates to the schema”; 2. review the language used at the independent claim, such as “updating metadata for the computer function to subsequently have the computer function call the higher version of the API”, such language does not necessary to be mean the update metadata is able to prevent the claimed invention will not perform validation repeatedly later if there is a new API request/call. The language of “subsequently” in view of other limitations under BRI can be 1. the claimed invention is able to allow execute the current API function call with the higher API version since this execution is “subsequent” to “the computer function call the higher version of the API OR 2. the claimed invention is able to allow execute the next/subsequent API function call only with the higher API version without another validation. If Applicant intends to mean the claimed invention is able to utilize the higher version of API whenever there is a related API request/call after a first or initial validation, then Applicant is suggested to amend the language to specific such feature.
First of all, Applicant is suggested to review the explanations or interpretations from Examiner for reference Leach. Such as, “the relation and indication discussed at [0030]-[0031] are considered as claimed metadata to be updated instead of object metadata discussed at [0030]-[0031]”, i.e., the term “metadata” from Leach is actually mapped to claimed API instead of claimed metadata and the term “relation” from Leach is actually mapped to claimed metadata. In addition to [0031] that Examiner already cited, either one of [0017], [0018], [0020] or [0036] from Leach discusses that the software application from Leach would use “metadata” from Leach to perform its action, i.e., software application uses/utilizes metadata from Leach is mapped or compared to claimed “at least one operation of a computer function that utilizes an application interface (API)”. The compatibility between higher version of metadata and current version of software application from Leach represents such current version of software application is able to use or utilizes such higher version of metadata to achieve its function, and thus the update of relation to indicate compatibility between higher version of metadata and current version of software application from Leach is reasonable to map or compare to claimed “updating metadata for the computer function to subsequently have the computer function call the higher version of the API”. Combining such feature from Leach into the teachings from Sager, then the combination of Sager and Leach would teach the claimed “responsive to determining that the first query validates to the schema for the higher version of the API, updating metadata for the computer function to subsequently have the computer function call the higher version of the API”.
Therefore, Claims 1-20 are rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Weissman et al. (US 20100299663 A1) discloses: By providing an indication of versions of calling to which each individual component of an application corresponds (e.g. by versioning the components as described above), backwards compatibility for the application may be maintained (see [0038]).
Jain et al. (US 20240256435 A1) discloses: Backward compatibility means having legacy implementation ability, thus while making changes on the request-response schema the existing clients are able to send requests and decode those responses. Henceforth, an API specification is said to be backward compatible with its newer or latest version, thus every specification under the older version is still valid. In an implementation, the old version of the API specification is executed by the test engine [110] to generate executable test cases for each set of scenario and the new version of the same API specification or a different API specification is implemented on the proxy server (see [0045]).
Ovchinnikov et al. (US 20230289635 A1) discloses: One of the ways to resolve the issue about validation of the backward compatibility of the new, modified version of the REST API is to launch a set of functional and end-to-end (e2e) tests. Before delivering to production, the set of tests from an earlier API version is executed against a new version. In the case of “green” (without failures) build, the new version of API can be accepted as having backward compatibility (see [0016]).
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 extension fee 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 ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights