DETAILED ACTION
1. Claims 2, 9 and 16 are amended.
2. Claims 1 and 19 are cancelled.
3. Claim 22 is added new.
4. Claim 2 – 18 and 20 – 22 have been examined and are pending.
5. This application is a continuation of Application # 18/488,922 now U.S. Patent 12166837.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 2 – 4, 6 – 7, 9 – 11, 13 – 14, 16 – 18 and 20 – 21 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 10,810,055 to Walker in view of US Patent Application Publication No. 2015/0229579 to Qamal Kosim-Satyaputra et al. (hereinafter Qamal).
Regarding Claim 2, Walker discloses (¶Col. 2, Lines 1 – 8) a shadow or testing environment for testing of an API call before executing the call in an actual target environment, which further includes:
system comprising: a processor and a computer-readable medium storing instructions that are operative upon execution by the processor (Walker discloses (¶Fig. 9), Processor 902 executing instructions stored in a memory 904) to:
receive, by an application programming interface (API) proxy, a first API call from an application (Walker discloses (¶Col. 12, Lines 9-13) client device utilize application programing interfaces (APIs) for generating, uploading and invoking the customer code (i.e. an application) and submitting a request), wherein the first API call comprises an API endpoint (Walker discloses (¶Col. 3, Lines 32-35) API endpoint 122, or API gateway 106, or API filtering proxy, to receive certain API calls, or other requests, sent from the client device 102 or other such sources)
provide, by the API proxy to the application, a guidance for a response from the API endpoint regarding the first API call (Walker discloses (Fig. 3 and ¶Col. 9 Lines 1-7) a user 302 wanting to utilize a portion of the resources 314 can submit a request i.e. first API call to the API Gateway 106 or API Filtering proxy. The resource manager 310 receive requests call for specific action to be performed with respect to the data environment, such as to provision, scale, clone, or hibernate an instance (¶Col. 9 Line 61 - ¶Col. 10 Line 4). Upon receiving a request to one of the APIs, the Web services portion of the interface layer provides guidance i.e. it can parse or otherwise analyze the request to determine the steps or actions needed to act on or process the call)
receive, by the API proxy, a second API call from the application (Walker discloses (¶Col. 12, Lines 9-13) client device utilize application programing interfaces (APIs) for generating, uploading and invoking the customer code (i.e. an application) and submitting a request), wherein the second API call comprises the API endpoint (Walker discloses (¶Col. 3, Lines 32-35) API endpoint 122, or API gateway 106, or API filtering proxy, to receive certain API calls, or other requests, sent from the client device 102 or other such sources),
determine, by the API proxy, that the second API call from the application is not in accordance with the guidance (Walker discloses (Fig. 1 and ¶Col. 22 Lines 15-48) a call is received at the API gateway 106 or API filtering proxy, and the actions of the call are modeled in the shadow copy of the database, and result of the modeling are analyzed, and a determination is made that results are against one or more rules, policies, requirements, regulations etc., hence the call is not compliant. Walker discloses (¶Col. 9, Line 57 – ¶Col. 10, Line 27) resource manager uses interface layer 308 authenticating customers based on credentials, authorizing the customer, throttling customer requests (¶Col. 10, Line 14) to the API servers, validating user input, marshalling or unmarshalling requests and providing responses (Walker, ¶Col. 6 Line 57) to the client device 102 by the API gateway 106)
Walker does not explicitly disclose send, by the API proxy to the application, a simulated response that limits the application from transmitting any future API calls that include the API endpoint for a time period. However, in an analogous art, Qamal teaches:
send, by the API proxy to the application, a simulated response that limits the application from transmitting any future API calls that include the API endpoint for a time period (Qamal teaches (¶14 and ¶40-¶41) send, by the API proxy (202 - fig. 2) to the application (API client 201 - fig. 2), a simulated response (i.e., API proxy system is responsible for returning an appropriate response to the client when the quota has been reached) that limits the application (i.e., application 201; ¶28-30) from transmitting any future API calls that include the API endpoint (204 - fig. 2) for a time period (i.e., API proxy system 202 may calculate quotas based on a resource limit with respect to a number of clients 201 accessing a resource 204 and include in the response or "simulated response" to the client some sort of timeout period or "limit for a time period" which the client can use to sleep their requests until the time window elapses. That is, application 201 cannot send any requests until the timeout period expires.)
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine a system comprising: a processor and a computer-readable medium storing instructions that are operative upon execution by the processor, to: receive, by an application programming interface (API) proxy, a first API call from an application, wherein the first API call comprises an API endpoint, provide, by the API proxy to the application, a guidance for a response from the API endpoint regarding the first API call, receive, by the API proxy, a second API call from the application, wherein the second API call comprises the API endpoint, determine, by the API proxy, that the second API call from the application is not in accordance with the guidance, as disclosed by Walker, and send, by the API proxy to the application, a simulated response that limits the application from transmitting any future API calls that include the API endpoint for a time period, as taught by Qamal, for the purpose of implementing systems and methods for limiting and distributing API rate usage among multiple applications in a multi-tenant platform (¶3).
Claim 3, Walker in view of Qamal discloses all the elements of claim 2. Further, they disclose:
wherein the API proxy comprises an API call evaluator that uses pattern analysis of API calls to determine whether the application is using guidance provided in responses to prior API calls (Walker discloses (¶Col. 5, Lines 5 – 20 and ¶Col. 9, Line 57 – ¶Col. 10, Line 25) resource manager 310 performs testing of the received API call, paring and analyzing the request to determine it in a shadow or testing environment before executing the call in the target environment. Walker describes (Figs. 6 and 7) modeling an API call, analyzing the log entries using a continuous monitoring service that monitors for compliance check (Figs. 2A/2B) comparing the results against one or more rules, policies, requirements, regulations, or compliance criteria, among other such options, and a determination is made as to whether the call is compliant with the requirements or regulations.)
The motivation to combine the references is similar to the reasons in Claim 2.
Claim 4, Walker in view of Qamal discloses all the elements of claim 2. Further, they disclose:
determine, by the API proxy, that the second API call exceeds a resource limiting parameter, and based on determining that the second API call exceeds the resource limiting parameter avoid, by the API proxy, forwarding the second API call to the API endpoint (Qamal discloses (¶40) API proxy system 202 is responsible for returning an appropriate response to the client when the quota has been reached for a configured time window. Thus, API proxy system 202 may calculate quotas based on a resource limit with respect to a number of clients accessing a resource and include in the response to the client some sort of timeout period which the client can use to sleep their requests until the time window elapse.)
The motivation to combine the references is similar to the reasons in Claim 2.
Claim 6, Walker in view of Qamal discloses all the elements of claim 2. Further, they disclose:
receive, by the API proxy, a third API call from the application (Walker discloses (¶Col. 12, Lines 9-13) client device utilize application programing interfaces (APIs) for generating, uploading and invoking the customer code (i.e. an application) and submitting a request), wherein the third API call comprises the API endpoint ((Walker discloses (¶Col. 3, Lines 32-35) API endpoint 122, or API gateway 106, or API filtering proxy, to receive certain API calls, or other requests, sent from the client device 102 or other such sources) forward the third API call to the API endpoint (Walker discloses (Fig. 3, ¶Col. 9 Lines 1 – 30) the interface layer 308 includes application programming interfaces (APIs) and it enables a user to submit requests and forwards it to the provider environment such as the application servers 314. The task manager (¶Col. 4, Lines 49 – 57) synthesize and make API calls to the target API endpoint 122 for the service or services being proxied) receive a response to the third API call from the API endpoint (Walker discloses (¶Col. 10 Lines 5 – 8) the interface layer 308 return the appropriate responses based on the API specifications) generate and add a simulated rate limiting response to the response to the third API call from the API endpoint (Qamal teaches (¶14 and ¶40-¶41) send, by the API proxy (202 - fig. 2) to the application (API client 201 - fig. 2), a simulated response (i.e., API proxy system is responsible for returning an appropriate response to the client when the quota has been reached) that limits the application (i.e., application 201) from transmitting any future API calls that include the API endpoint (204 - fig. 2) for a time period (i.e., API proxy system 202 may calculate quotas based on a resource limit with respect to a number of clients 201 accessing a resource 204 and include in the response or "simulated response" to the client some sort of timeout period or "limit for a time period" which the client can use to sleep their requests until the time window elapses. That is, application 201 cannot send any requests until the timeout period expires.)
The motivation to combine the references is similar to the reasons in Claim 2.
Claim 7, Walker in view of Qamal discloses all the elements of claim 6. Further, they disclose:
receive, by the API proxy, a fourth API call from the application (Walker discloses (¶Col. 12, Lines 9-13) client device utilize application programing interfaces (APIs) for generating, uploading and invoking the customer code (i.e. an application) and submitting a request), wherein the fourth API call comprises the API endpoint (Walker discloses (Fig. 3, ¶Col. 8 Lines 48 – 61) a client device 302 submitting an API request to a provider environment such as a multi-tenant resource provider environment 306) determine whether the fourth API call complies with the simulated rate limiting response Walker discloses (¶Col. 4 Lines 22 – 27) simulating API calls and determining whether the API call should be allowed to execute) and based on determining that the fourth API call does not comply, send, by the API proxy to the application, a simulated throttling response (Walker discloses (¶Col. 10 Lines 5 – 16) the interface layer 308 is responsible for validating user input, throttling customer requests to the API servers, and marshalling or unmarshalling requests and responses.)
The motivation to combine the references is similar to the reasons in Claim 2.
Claim 9, do not teach or further define over the limitations in claim 2. Therefore, claim 9 is rejected for the same rationale of rejection as set forth in claim 2.
Claim 10, do not teach or further define over the limitations in claim 3. Therefore, claim 10 is rejected for the same rationale of rejection as set forth in claim 3.
Claim 11, do not teach or further define over the limitations in claim 4. Therefore, claim 11 is rejected for the same rationale of rejection as set forth in claim 4.
Claim 13, do not teach or further define over the limitations in claim 6. Therefore, claim 13 is rejected for the same rationale of rejection as set forth in claim 6.
Claim 14, do not teach or further define over the limitations in claim 7. Therefore, claim 14 is rejected for the same rationale of rejection as set forth in claim 7.
Claim 16, do not teach or further define over the limitations in claim 2. Therefore, claim 16 is rejected for the same rationale of rejection as set forth in claim 2.
Claim 17, do not teach or further define over the limitations in claim 3. Therefore, claim 17 is rejected for the same rationale of rejection as set forth in claim 3.
Claim 18, do not teach or further define over the limitations in claim 4. Therefore, claim 18 is rejected for the same rationale of rejection as set forth in claim 4.
Claim 20, do not teach or further define over the limitations in claim 6. Therefore, claim 20 is rejected for the same rationale of rejection as set forth in claim 6.
Claim 21, do not teach or further define over the limitations in claim 7. Therefore, claim 21 is rejected for the same rationale of rejection as set forth in claim 7.
Claim 22, Walker in view of Qamal discloses all the elements of claim 2. Further, they disclose:
wherein the simulated response is returned by the API proxy without triggering a throttling response from the API endpoint (Qamal discloses (¶40) API proxy system 202 is responsible for returning an appropriate response notifying the client when the quota has been reached for a configured time window. Thus, API proxy system 202 may calculate quotas based on a resource limit with respect to a number of clients accessing a resource and include in the response to the client some sort of timeout period which the client can use to sleep their requests until the time window elapse. ¶41 API proxy system 202 can handle any API client that is making too many requests (and therefore should be throttled back) during a certain time window without involving tenant 204)
The motivation to combine the references is similar to the reasons in Claim 2.
Claims 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 10,810,055 to Walker, in view of US Patent Application Publication No. 2015/0229579 to Qamal and in view of US Patent Application Publication No. 2024/0095127 to Kumar et al. (hereinafter Kumar).
Claim 8, Walker in view of Qamal discloses all the elements of claim 2. Walker in view of Qamal does not explicitly disclose determining record API calls received by the API proxy and responses to the application and train a machine learning model of the API proxy based on the recorded API calls and the responses. However, in an analogous art, Kumar teaches:
record API calls received by the API proxy and responses to the application (Kumar teaches (¶176, ¶194) using the requests from clients, the results from clients, and possibly data from other sources, and employing machine learning algorithms to implement (¶61) the case in which the client makes a request to an API Endpoint and exceeds rate-limits imposed by the API. In this implementation case, when the client makes requests to the API at a rate more than the rate-limit, the API throttles the request and the API returns a throttled response. The response contains a retry-after header and the retry-after header may contain a retry-after interval and/or scopes)
and train a machine learning model of the API proxy based on the recorded API calls and the responses (Kumar teaches (¶231, ¶412) machine learning technique (e.g., a neural network) may be utilized in combination with monitoring to determine which of the scopes specified in the API call permission request were under heavy load (e.g., based on an absolute performance benchmark, compared to other scopes, and/or the like) at the time the API throttled the API call, and such heavy load scopes may be used as the set of scopes associated with the API call result request.)
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine a system comprising: a processor and a computer-readable medium storing instructions that are operative upon execution by the processor, to: receive, by an application programming interface (API) proxy, a first API call from an application, wherein the first API call comprises an API endpoint, provide, by the API proxy to the application, a guidance for a response from the API endpoint regarding the first API call, receive, by the API proxy, a second API call from the application, wherein the second API call comprises the API endpoint, determine, by the API proxy, that the second API call from the application is not in accordance with the guidance, and send, by the API proxy to the application, a simulated response that limits the application from transmitting any future API calls that include the API endpoint for a time period, as disclosed by Walker in view of Qamal, and determining record API calls received by the API proxy and responses to the application and train a machine learning model of the API proxy based on the recorded API calls and the responses, as taught by Kumar, for the purpose of (¶68) implementing an adaptive rate limiting gatekeeper apparatus that may be utilized to minimize the risk that an API will throttle clients’ requests.
Claim 15, do not teach or further define over the limitations in claim 8. Therefore, claim 15 is rejected for the same rationale of rejection as set forth in claim 8.
Claims 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 10,810,055 to Walker, in view of US Patent Application Publication No. 2015/0229579 to Qamal and in view of US Patent Application Publication No. 2024/0064195 to Palladino et al. (hereinafter Palladino).
Claim 5, Walker in view of Qamal discloses all the elements of claim 2. Walker in view of Qamal does not explicitly disclose determining a difference between an API specification for the API endpoint and the response from the API endpoint and generate an alert based at least on the difference. However, in an analogous art, Palladino teaches:
determine a difference between an API specification for the API endpoint and the response from the API endpoint (Palladino teaches (Fig. 9 and ¶85 - ¶86) a gateway node receives a client request, and the gateway node proxies the request and receives a response from the API. The response is sent back to the client. The gateway node parses both the request and the response, and retrieves the documentation for the endpoint requested. Upon retrieving the prior documentation, the gateway node compares the prior documentation with the current request to identify differences)
and generate an alert based at least on the difference (Palladino teaches (Fig. 9 and ¶85 - ¶86) if the gateway node determines (at step 926) that there is a difference in the retrieved documentation and the current request and response data, then the gateway node alerts/notifies a user via an internal alert module, sending an email to the user, or using a third-party notification service.)
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine a system comprising: a processor and a computer-readable medium storing instructions that are operative upon execution by the processor, to: receive, by an application programming interface (API) proxy, a first API call from an application, wherein the first API call comprises an API endpoint, provide, by the API proxy to the application, a guidance for a response from the API endpoint regarding the first API call, receive, by the API proxy, a second API call from the application, wherein the second API call comprises the API endpoint, determine, by the API proxy, that the second API call from the application is not in accordance with the guidance, and send, by the API proxy to the application, a simulated response that limits the application from transmitting any future API calls that include the API endpoint for a time period, as disclosed by Walker in view of Qamal, and determine a difference between an API specification for the API endpoint and the response from the API endpoint, and generate an alert based at least on the difference, as taught by Palladino, for the purpose of (¶19) automatically generate or update documentation for an API by monitoring, parsing, and sniffing requests/responses to/from the API through network nodes such as proxy servers, gateways, and control planes.
Claim 12, do not teach or further define over the limitations in claim 5. Therefore, claim 12 is rejected for the same rationale of rejection as set forth in claim 5.
Response to Arguments
Claim Rejections - 35 USC § 103
Applicant’s arguments and amendments, filed on 05/27/2026 with respect to the Claims 2 – 18 and 20 – 22 have been fully considered and they are persuasive. Hence, the 35 USC § 103 rejection is withdrawn. However, based on the claim amendments, arguments and the newly introduced limitations, the search is updated and a new reference, US Patent Application Publication No. 2015/0229579 to Qamal Kosim-Satyaputra et al. has been introduced for the 35 USC § 103 rejection. Hence, the arguments related to Claims 2 – 18 and 20 – 22 are moot.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HASSAN ABDUR-RAHMAN KHAN whose telephone number is (313)446-6574. The examiner can normally be reached TEAPP - (M-Sa) 9/30/17-9/30/18, 6am-10pm IFP.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry can be reached at (571) 272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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.
/H. A. K./
Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Prosecution Insights