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 .
Claims 2 – 21 have been examined and are pending.
This application is a continuation of Application # 18/488,922 now U.S. Patent 12166837.
Drawings
The applicant’s submitted drawings are acceptable for examination purposes.
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 – 11, 13 – 18 and 20 – 21 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 10,810,055 to Walker, and in view of US Patent Application Publication No. 2024/0095127 to Kumar et al. (hereinafter Kumar).
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)
send, by the API proxy to the application, a simulated response to cause the application to delay transmitting any more API calls comprising the API endpoint (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, and marshalling or unmarshalling requests and responses. The response is provided (Walker, ¶Col. 6 Line 57) to the client device 102 by the API gateway 106.)
Walker does not explicitly discloses delaying transmitting any more API calls comprising the API endpoint for a time period. However, in an analogous art, Kumar teaches:
discloses delaying transmitting any more API calls comprising the API endpoint for a time period (Kumar teaches (Fig. 1c and ¶155) gatekeeper calls GetRetryAfter that uses the stored value which indicates the time that a request should wait before it reaches the API to minimize the risk that the API will throttle the request. When GetRetryAfter returns a (e.g., non-negative) non-zero value to the gatekeeper, that value indicates to the gatekeeper the time that a request should wait before it reaches the API to minimize the risk that the API will throttle the 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, send, by the API proxy to the application, a simulated response to cause the application to delay transmitting any more API calls comprising the API endpoint and delaying transmitting any more API calls comprising the API endpoint for a time period, as taught by Kumar, for the purpose of implementing (¶68) fleetwide adaptive rate limiting gatekeeper apparatuses, processes and systems that is utilized to manage the API requests and to minimize the risk that an API will throttle clients' request.
Claim 3, Walker in view of Kumar 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 Kumar 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 (Walker discloses (¶Col. 12, Lines 47 – 52) the resource service can handle the acquisition and configuration of compute capacity (e.g., containers, instances, etc.) based on the code execution request, and execute the code using the compute capacity, and the allocation is automatically scale up and down based on the volume) avoid, by the API proxy, forwarding the second API call to the API endpoint (Walker discloses (¶Col. 6, Lines 55 – 60) if the response is one of non-compliance, an http 403 (or other) response can be synthesized or otherwise generated to be provided to the client device 102 via the API gateway 106, and the actual API endpoint(s) 122 can be prevented from being called directly by the client device).
The motivation to combine the references is similar to the reasons in Claim 2.
Claim 6, Walker in view of Kumar 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 (Walker discloses (¶Col. 4 Lines 22 – 27) simulating API calls. 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 7, Walker in view of Kumar 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 8, Walker in view of Kumar discloses all the elements of claim 2. Further, they disclose:
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)
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.)
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 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.
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.
Claims 5, 12 and 19 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. 2024/0095127 to Kumar, and in view of US Patent Application Publication No. 2024/0064195 to Palladino et al. (hereinafter Palladino).
Claim 5, Walker in view of Kumar discloses all the elements of claim 2. Walker in view of Kumar does not explicitly discloses 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, send, by the API proxy to the application, a simulated response to cause the application to delay transmitting any more API calls comprising the API endpoint for a time period, as disclosed by Walker in view of Kumar, 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.
Claim 19, do not teach or further define over the limitations in claim 5. Therefore, claim 19 is rejected for the same rationale of rejection as set forth in claim 5.
Conclusion
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
U.S. Patent Application Publication No. 2020/0348986 to Venkatesh et al. (Intelligent Application Programming Interface (API) Proxy Design System)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HASSAN KHAN whose telephone number is (313) 446-6574 and fax number is (571) 483-7559. The examiner can normally be reached on MONDAY - THURSDAY.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Christopher L. Parry can be reached on (571) 272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent- center for more information about Patent Center and https:/Awww.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.
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:/Awww.uspto.gov/interviewpractice.
/H. A. K./
Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451