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 the communication filed 11/20/2023.
Claims 1-20 are presented for examination.
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.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/20/2023. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 7, 9 and 19 are objected to because of the following informalities:
“the latest version” at line 2 of claim 7 should be: a latest version.
“the same computing environment” at lines 1-2 of claim 9 should be: a same computing environment.
“the latest version” at line 2 of claim 19 should be: a latest version.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Regarding to Claim 20, Claim 20 recites a computer-readable medium including executable instructions. However, paragraphs [0038] of the specification is silent to explicitly define “a computer-readable medium excluding signals and/or carrier wave. Further, paragraphs [0087] from the specification describes computer readable media as “computer readable media such as transitory or non-transitory storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information”. Such description under the broadest reasonable interpretation to include signals (see MPEP 2111, examiner obliged to give the terms or phrases their broadest interpretation definition awarded by one of an ordinary skill in the art unless applicant has provided some indication of the definition of the claimed terms or phrases, as such "the like" include other type of medium). Signals are directed to a non-statutory subject matter. Thus, Claim 20 is rejected under 35 U.S.C. 101 for directing to a non-statutory subject matter. Examiner suggests amend the claim element as non-transitory computer-readable medium in order to draw the claim to non-transitory subject matter.
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), 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 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 the first 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”).
Sagar does not disclose: responsive to the first query validating to the schema, 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 the 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 the 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, 17. 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).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Evans (US 5179703 A) discloses: validating each system command against the parameters of its retrieved command definition associated with a different version (see claims 1 and 3).
Chennoor (US 20220357979 A1) discloses: rejecting an invalidated API request (see [0013]).
Schneider (US 20090138956 A1) discloses: a test module coupled between the application interface and the client interface to inject faults into the interactions between the plurality of applications and the client to test a communication protocol adopted by the plurality of applications and the client (see claim 13).
D O et al. (US 20230129951 A1) discloses: re-test application interfaces that failed to validate whether re-loaded application interfaces include the corresponding success indicator. That is, application that did not pass testing (e.g., applications that did not provide an application interface including the corresponding success indicator) may be tested a second time (see [0036]).
Nath et al. (US 20220391314 A1) discloses: to test the application, application developers typically had two traditional approaches. First is to inject fault conditions within the application program code to simulate the faults in underlying systems and validate handling of the faults (see [0021]).
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