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 Applicant’s amendments filed on 12/16/2025. Claims 1-4, 6-12, and 14-20 remain pending in the application. Claims 1-3, 8-10, and 15-17 have been amended. Claims 5 and 13 have been canceled. Any examiner’s note, objection, and rejection not repeated is withdrawn due to Applicant’s amendment.
Examiner’s Note
The 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 also apply. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in its entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-4 and 6-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, it recites “when the given single-action API call is part of a burst, throttling the burst, wherein throttling the burst includes detecting whether an error message has been generated for any of N API calls that are part of the burst and immediately precede the API call”. The phrase “the API call” is unclear as to whether the phrase refers to the given single-action API call or to one of the plurality of API calls in the burst. For the purposes of examination, the examiner assumes “the given single-action API call” was intended.
Any claim not explicitly mentioned above is rejected due to dependency on a rejected claim.
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.
Claims 1, 3, 6, 8, 10, 15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sem et al. (US 11138033 B1) hereafter Sem in view of Michels et al. (US 20080209451 A1) hereafter Michels, further in view of Kumar et al. (US 20240095127 A1) hereafter Kumar, further in view of Garvey et al. (US 20200394089 A1) hereafter Garvey.
Regarding claim 1, Sem teaches:
receiving, at a computing system, a given Application Programming Interface (API) call, the given API call being transmitted by a sender, the given API call being associated with a given operation (Col. 3, lines 5-14; “In some cases, a user desires to send a large number of requests to an API in a short period of time. In the example above of a batch processing service, a user might desire to send a large number of “submit job” API requests to submit a large number of new compute jobs desired for execution by the batch processing service. To submit the compute jobs, the user can first configure the batch processing service to execute the jobs (for example, including configuring a compute environment to execute the jobs and creating a queue to receive the compute jobs)”, where the queue receiving the API requests corresponds to receiving, at the computing system, a given API call transmitted by a sender);
detecting whether the given API call is part of a burst of API calls, wherein detecting whether the given single-action API call is part of the burst includes detecting whether a plurality of single-action API calls that are associated with the given operation have been received from the sender of the given single-action API call in a predetermined time window (Col. 5, lines 14-19; “Although the example shown in reference to FIG. 1 involves using a bulk task API request to submit any number of compute jobs to a batch processing service 102, in general, similar processes can be used to submit a plurality of computing tasks to an application or service using only a single API request”. Sem further teaches, in Col. 5 lines 37-51, “submit a plurality of computing tasks… near in time to one another” corresponds to a burst of API calls because it describes many such API requests clustered closely together in time. “bulk task data… describing the set of computing tasks” corresponds to the plurality of API calls associated with a given operation because the tasks in the set are grouped together for the same submission. “a user creates bulk task data” corresponds to the sender of the given single action API call because the request originates from a single user. “near in time to one another” corresponds to a predetermined time window because it describes temporal clustering of requests. A system that accepts tasks submitted near in time while handling rate-limiting, batching, and execution scheduling, must detect that the tasks are part of a set or burst in order to properly handle the incoming submissions.);
a single action API call (Col. 5, lines 43-47; “to enable users to generate a single API request to submit the plurality of computing tasks for execution, a user creates bulk task data 120 describing the set of computing tasks that the user desires to be executed by one or more services of the service provider network 100”. One such computing task within the set of computing tasks corresponds to an API call that performs a single action.);
Sem does not teach an explicit burst API call; throttling the burst, wherein throttling the burst includes detecting whether an error message has been generated for any of N API calls that are part of the burst; immediately precede the API call; when the given API call is part of a burst, generating an error message in response to the given API call and returning the error message to the sender of the given API call; and when the given API call is not part of a burst, executing the given API call; and if an error message has been generated for any of the N API calls, executing the given single-action API call, wherein N is a positive integer greater than one.
However, Michels teaches:
when the given API call is part of a burst, if no error message has been generated for any of the N API calls, generating an error message in response to the given API call and returning the error message to the sender of the given API call (Paragraph 77; “send an HTTP/1.1 403 error” corresponds to generating an error message in response and returning the error message to the sender because it explicitly describes sending an error back to the sender when a particular developer causes “overloading the API server 118 from a burst of API calls”, which also discloses the burst API call. Generating an error message for the API call necessarily implies that, at that particular point in time, no such error message had yet been generated for that triggering condition. Because the act of generating the error message is performed in response to detecting that condition for the first time, the prior art teaches the claimed generation of an error message when no prior error message had yet been generated for the plurality of API calls.);
and when the given API call is not part of a burst, executing the given API call without throttling the burst (Paragraph 77; “API server 118 will accept [API calls]” corresponds to executing the API call when not part of a burst because the system processes the call normally unless it violates the burst/rate limit, where normal execution implies that the burst was not throttled.);
and if an error message has been generated for any of the N API calls, executing the given API call, wherein N is a positive integer greater than one (Paragraph 77; “If the developer exceeds the limit, the proxy server 104 may return a 403 error, issue a notification but continue to allow access, issue notification but allow access up to a certain high level of overage, and/or accept traffic up to a certain level for free, but charge for additional access that exceeds the free limit.”, where the 403 error corresponds to an error message being generated for any of the API calls, the number of API calls being a plurality corresponding to N being a positive integer greater than one. Continuing to allow access corresponds to allowing execution of the given API call.).
Sem and Michels are considered to be analogous to the claimed invention because they are in the same field of API call throughput management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sem to incorporate the teachings of Michels and generate an error message in response to a given single action API call when detected as part of a burst, return an error message to the sender, and execute the API call when not part of a burst. A person of ordinary skill in the art would have recognized the need to prevent resource overload of the API server while ensuring normal operation for legitimate single requests. Unchecked burst API calls risk degraded quality of service and excessive resource consumption.
Sem in view of Michels does not teach throttling the burst, wherein throttling the burst includes detecting whether an error message has been generated for any of N API calls that are part of the burst; or detecting events that immediately precede the API call.
However, Kumar teaches:
throttling the burst, wherein throttling the burst includes detecting whether an error message has been generated for any of N API calls that are part of the burst (Paragraphs 224-229; “if there is a (e.g., non-zero) retry-after interval stored for the selected scope, the API previously returned a throttled response for that scope” (Paragraph 224), and further, “a determination may be made... whether a retry-after interval exists for any of the scopes” (Paragraph 225). The “throttled response” and “API call permission denied response” (Paragraph 229) correspond to the error message response. The act of determining whether a retry-after interval exists constitutes detecting whether an error message has been generated, because the retry-after interval is stored as a result of a prior throttled, thereby error, response. The evaluation across any of the scopes corresponds to detecting whether such an error has been generated for any of a plurality of API calls since each scope represents a set of API interactions subject to throttling. Throttling the burst is further disclosed in Paragraph 224, “In one embodiment, if there is a (e.g., non-zero) retry-after interval stored for the selected scope, the API previously returned a throttled response for that scope, and the client should wait for the retry-after interval to minimize the risk that the API will throttle the API call”, where the API explicitly throttles the API call.).
Sem, Michels, and Kumar are considered to be analogous to the claimed invention because they are in the same field of API call throughput management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sem in view of Michels to incorporate the teachings of Kumar and throttled the burst, including detecting whether any API call of the burst had an error message generated. A person of ordinary skill in the art would have recognized that API throttling and error checks are known methods in the art yielding the predictable result of allowing the system to recognize when a burst of API calls that had been throttled has already had an error message generated.
Sem in view of Michels, further in view of Kumar does not teach detecting events that immediately precede the API call.
However, Garvey teaches:
detecting events that immediately precede the API call (Paragraph 15; “pre-API logic or structure portion (depicted above a dotted demarcation line 203 relative to element 206) that includes processes 204, 232, 234 and 236, wherein said pre-API portion checks for any API failure prior to making the call at 206”, where the temporal check before the call corresponds to the detection of events that immediately precede the API call.).
Sem, Michels, Kumar, and Garvey are considered to be analogous to the claimed invention because they are in the same field of API call throughput management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sem in view of Michels further in view of Kumar to incorporate the teachings of Garvey and have incorporated the idea of checking events that precede the API call into the system of Sem in view of Michels, further in view of Kumar. A person of ordinary skill in the art would have recognized the use of a temporal relation lookup to be a known method in the art whose implementation would yield the predictable result of providing the capability to identify if an event, in this case, an error message, had occurred within a related group of API calls.
Claim 8 recites similar limitations as those of claim 1, additionally reciting a memory and a processor; an Application Programming Interface that is executed by the at least one processor; performing a search of a database; wherein no two consecutive ones of the plurality of single-action API calls are delayed from one another by longer than a predetermined threshold delay; the database being configured to store information about single-action API calls. Sem teaches:
a memory; and a processor (Col. 14, lines 23-47);
an Application Programming Interface that is executed by the at least one processor (Col. 10, lines 20-30; “FIG. 6 is a flow diagram illustrating operations 600 of a method for providing an application programming interface (API)... executing collectively on one or more processors”).
Kumar teaches:
performing a search of a database (Paragraph 224; “For example, the retry-after interval for selected scope may be retrieved via a MySQL database command”, the MySQL database command corresponding to performing a search of a database for API calls.);
the database being configured to store information about single-action API calls (Paragraphs 224-225; “the retry-after interval for selected scope may be retrieved via a MySQL database command” and “A determination may be made at 1025 whether a retry-after interval exists for any of the scopes in the set of scopes”, where the database is a repository of prior API call information containing retry-after intervals, scopes, and API type, and the individual scopes contain information of single action API calls and throttling responses, therefore the database is configured to store information about single-action API calls.).
wherein no two consecutive ones of the plurality of single-action API calls are delayed from one another by longer than a predetermined threshold delay (Paragraph 67; “another client... may make the next request within the time interval specified by the retry-after header”, which represents a predetermined temporal upper and lower bound governing when subsequent API calls may occur relative to prior calls. Because the next call is made within the time interval, the delay between consecutive API calls is constrained relative to this interval and corresponds to a condition in which no two consecutive API calls are delayed from one another by longer than a predetermined threshold delay.).
Sem, Michels, and Kumar are considered to be analogous to the claimed invention because they are in the same field of API call throughput management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sem in view of Michels to incorporate the additional teachings of Kumar of performing a search of a database configured to store information about single-action API calls and have no two consecutive single-action API calls be delayed by longer than a predetermined threshold. A person of ordinary skill in the art would recognize the use of a database repository and maximum threshold delay to track prior API calls and limit consecutive calls to be a known method in the art yielding the predictable result of allowing control of order and spacing of API calls based on historical data and API limits.
Claim 8 is rejected for similar reasons as those of claim 1.
Claim 15 recites similar limitations as those of claim 1, additionally reciting a non-transitory computer-readable storage medium. Sem teaches:
a non-transitory computer-readable storage medium (Col. 15, lines 42-62).
an Application Programming Interface that is executed by the at least one processor (Col. 10, lines 20-30; “FIG. 6 is a flow diagram illustrating operations 600 of a method for providing an application programming interface (API)... executing collectively on one or more processors”).
Kumar teaches:
performing a search of a database (Paragraph 224; “For example, the retry-after interval for selected scope may be retrieved via a MySQL database command”, the MySQL database command corresponding to performing a search of a database for API calls.);
the database being configured to store information about single-action API calls (Paragraphs 224-225; “the retry-after interval for selected scope may be retrieved via a MySQL database command” and “A determination may be made at 1025 whether a retry-after interval exists for any of the scopes in the set of scopes”, where the database is a repository of prior API call information containing retry-after intervals, scopes, and API type, and the individual scopes contain information of single action API calls and throttling responses, therefore the database is configured to store information about single-action API calls.).
wherein no two consecutive ones of the plurality of single-action API calls are delayed from one another by longer than a predetermined threshold delay (Paragraph 67; “another client... may make the next request within the time interval specified by the retry-after header”, which represents a predetermined temporal upper and lower bound governing when subsequent API calls may occur relative to prior calls. Because the next call is made within the time interval, the delay between consecutive API calls is constrained relative to this interval and corresponds to a condition in which no two consecutive API calls are delayed from one another by longer than a predetermined threshold delay.).
Sem, Michels, and Kumar are considered to be analogous to the claimed invention because they are in the same field of API call throughput management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sem in view of Michels to incorporate the additional teachings of Kumar of performing a search of a database configured to store information about single-action API calls and have no two consecutive single-action API calls be delayed by longer than a predetermined threshold. A person of ordinary skill in the art would recognize the use of a database repository and maximum threshold delay to track prior API calls and limit consecutive calls to be a known method in the art yielding the predictable result of allowing control of order and spacing of API calls based on historical data and API limits.
Claim 15 is rejected for similar reasons as those of claim 1.
Regarding claim 3, Sem in view of Michels, further in view of Kumar, further in view of Garvey teach the method of claim 1. Michels teaches:
generating an error message when bursts occur (Paragraph 77; “The first form is where the API provider specifies how many API calls per second that the API server 118 will accept from a particular developer key to avoid a particular developer from overloading the API server 118 from a burst of API calls. If the developer exceeds the limit, the proxy server 104 may send an HTTP/1.1 403 error”, where the proxy server sending a 403 error upon overloading the API server from a burst of API calls corresponds to the generation of an error message when bursts occur).
Sem teaches:
generating the error message includes identifying a bulk-action API call that corresponds to the given single-action API call, and inserting, in the error message, an identifier of the bulk-action API call (Col. 5, lines 37-51; “to enable users to generate s single API request to submit the plurality of computing tasks for execution, a user creates bulk task data 120 describing the set of computing tasks” corresponding to bulk action API calls);
the given single-action API call is an API call, which, when executed, causes the given operation to be performed once (Col. 5, lines 37-51; “users [may] submit a plurality of computing tasks (for example, compute jobs…)” corresponds to a given single action API call causing the given operation to be performed once. Submission of a single computing task is an implicit single action API call where each call triggers one operation);
the bulk-action API call that corresponds to the given single-action API call is an API call, which, when executed, causes the given operation to be performed multiple times (Col. 5, lines 37-51; “to enable users to generate a single API request to submit the plurality of computing tasks for execution, a user creates bulk task data 120 describing the set of computing tasks…” corresponds to a bulk action API call corresponding to the single API call that causes an operation to be performed multiple times. One request is capable of performing multiple operations, which may include “compute jobs” multiple times).
Claim 10 recites similar limitations as those of claim 3. Claim 10 is rejected for similar reasons as those of claim 3.
Claim 17 recites similar limitations as those of claim 3. Claim 17 is rejected for similar reasons as those of claim 3.
Regarding claim 6, Sem in view of Michels, further in view of Kumar, further in view of Garvey teach the method of claim 1. Michels teaches:
wherein detecting whether the given single-action API call is part of the burst further includes detecting whether a time delay between any two consecutive single-action API calls from the plurality is less than a predetermined threshold (Paragraph 77; “In certain embodiments, the proxy server 104 supports at least two forms of rate limiting for access to an API. The first form is where the API provider specifies how many API calls per second that the API server 118 will accept from a particular developer key to avoid a particular developer from overloading the API server 118 from a burst of API calls. If the developer exceeds the limit, the proxy server 104 may send an HTTP/1.1 403 error ("Forbidden--Over rate limit") until the next second begins. The second form is where the API provider specifies how many calls each developer key can make over a predetermined period of time (e.g., day, week, or month). If the developer exceeds the limit, the proxy server 104 may return a 403 error, issue a notification but continue to allow access, issue notification but allow access up to a certain high level of overage, and/or accept traffic up to a certain level for free, but charge for additional access that exceeds the free limit” corresponds to a predetermined time window for counting calls. The temporal notion corresponds to the time delay less than a predetermined threshold, implemented as either a fixed window count or as an inter-arrival window. If the provider allows N calls per second, Michel’s teaching of per-second limits directly supports the detection step where the inter-call time delta < a predetermined threshold. Further, Michels explicitly discloses a predetermined threshold in the threshold pre-set by the provider: “The first form is where the API provider specifies how many API calls per second that the API server 118 will accept”).
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Sem in view of Michels, further in view of Kumar, further in view of Garvey, further in view of Kamalakantha et al. (US 20170351536 A1) hereafter Kamalakantha.
Regarding claim 2, Sem in view of Michels, further in view of Kumar, further in view of Garvey teach the method of claim 1. Michels teaches:
predetermined time windows (Paragraph 77; “The first form is where the API provider specifies how many API calls per second that the API server 118 will accept” explicitly teaches a predetermined time window, determined by the API provider);
wherein the error message is generated and returned only when the burst matches at least one of the prior patterns of API calls (Paragraph 77; “The first form is where the API provider specifies how many API calls per second that the API server 118 will accept from a particular developer key to avoid a particular developer from overloading the API server 118 from a burst of API calls. If the developer exceeds the limit, the proxy server 104 may send an HTTP/1.1 403 error ("Forbidden--Over rate limit") until the next second begins”, corresponding to generating an error message when a condition, corresponding to the prior pattern, is met);
and the given single-action API call is executed when the given single-action API is part of burst, but the burst does not match any of the prior patterns of API calls (Paragraph 77; “issue a notification but continue to allow access…” teaches that even if part of a burst, a system may still allow execution).
Sem in view of Michels, further in view of Kumar, further in view of Garvey does not teach comparing the API calls to one or more prior patterns of API calls to determine whether it matches any of the prior patterns of API calls.
However, Kamalakantha teaches:
comparing the API calls to one or more prior patterns of API calls to determine whether it matches any of the prior patterns of API calls (Paragraph 19; “compare… using direct comparison, pattern matching…” corresponds to comparing the burst to one or more patterns of API calls because it teaches identifying API calls by comparing against known patterns/signatures.).
Sem, Michels, Kumar, Garvey, and Kamalakantha are considered to be analogous to the claimed invention because they are in the same field of API throughput management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sem in view of Michels, further in view of Kumar, further in view of Garvey to incorporate the teachings of Kamalakantha and have compared a detected burst of API calls to previously observed patterns of API calls across the time windows as taught by Michels. Such a combination to a person of ordinary skill in the art would have predictably yielded conditional enforcement actions based on whether a selected burst conforms to previously observed patterns, which would increase efficiency and reduce false positives in overload protection.
Claim 9 recites similar limitations as those of claim 2. Claim 9 is rejected for similar reasons as those of claim 2.
Claim 16 recites similar limitations as those of claim 2. Claim 16 is rejected for similar reasons as those of claim 2.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sem in view of Michels, further in view of Kumar, further in view of Garvey, further in view of Caudill et al. (US 11467887 B1) hereafter Caudill.
Regarding claim 4, Sem in view of Michels, further in view of Kumar, further in view of Garvey teaches the method of claim 1. Michels teaches:
wherein generating the error message includes inserting in the error message a message for a user to use a bulk-action API call instead of the burst of API calls (Paragraph 77; “The first form is where the API provider specifies how many API calls per second that the API server 118 will accept from a particular developer key to avoid a particular developer from overloading the API server 118 from a burst of API calls. If the developer exceeds the limit, the proxy server 104 may send an HTTP/1.1 403 error” corresponds to having inserted an HTTP error message notifying a caller in response to a burst API call).
Sem teaches:
usage of a bulk-action API call (Col. 5, lines 37-51; “to enable users to generate a single API request to submit a plurality of computing tasks…” and “the bulk task data 120 includes a task list 134” corresponds to a user being able to submit many tasks via a single bulk task call).
Sem in view of Michels, further in view of Kumar, further in view of Garvey does not explicitly teach using a prompt.
However, Caudill teaches:
using a prompt (Col. 12, lines 34-36; “The panel may selectively prompt the user based on values and/or parameters that are relevant or pertinent to the ultimate API chain”).
Sem, Michels, Kumar, Garvey, and Caudill are considered to be analogous to the claimed invention because they are in the same field of API throughput management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sem in view of Michels, further in view of Kumar, further in view of Garvey to incorporate the teachings of Caudill and use a prompt. A person of ordinary skill in the art would have recognized the use of a prompt to be a logical design decision to improve UX. Further, it would have been obvious to a person of ordinary skill in the art to have inserted in the returned error/notification as taught by Michels a prompt to utilize the caller to use the bulk API as taught by Sem when an unnecessary burst API call is identified. A person of ordinary skill in the art would recognize that this would align with best practices for API design, improving throughput and yielding fewer rate limit violations.
Claim 11 recites similar limitations as those of claim 4. Claim 11 is rejected for similar reasons as those of claim 4.
Claim 18 recites similar limitations as those of claim 4. Claim 18 is rejected for similar reasons as those of claim 4.
Claims 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Sem in view of Michels, further in view of Kumar, further in view of Garvey, further in view of Burger et al. (US 5097533 A) hereafter Burger.
Regarding claim 12, Sem in view of Michels, further in view of Kumar, further in view of Garvey teach the system of claim 8. Sem teaches:
a single-action API call (Col. 5, lines 37-51; “users [may] submit a plurality of computing tasks (for example, compute jobs…)” corresponds to a single action API call. Submission of a single computing task is an implicit single action API call where each call triggers one operation).
Michels teaches:
detecting a burst API call (Paragraph 77; “The first form is where the API provider specifies how many API calls per second that the API server 118 will accept from a particular developer key to avoid a particular developer from overloading the API server 118 from a burst of API calls”, which explicitly discloses a burst of API calls);
wherein the error message is generated and returned (Paragraph 77; “The first form is where the API provider specifies how many API calls per second that the API server 118 will accept from a particular developer key to avoid a particular developer from overloading the API server 118 from a burst of API calls. If the developer exceeds the limit, the proxy server 104 may send an HTTP/1.1 403 error”, disclosing error message generation in burst contexts, corresponding to rules on when errors are sent. This also implies that calls may be executed once an error condition is reset or otherwise satisfied);
and executing the given single-action API call when a respective error message has been returned in response to any of the predetermined number of API calls (Paragraph 77; “If the developer exceeds the limit, the proxy server 104 may return a 403 error, issue a notification but continue to allow access, issue notification but allow access up to a certain high level of overage, and/or accept traffic up to a certain level for free, but charge for additional access that exceeds the free limit.”, where the 403 error corresponds to an error message being generated for any of the API calls, the number of API calls being a plurality corresponding to N being a positive integer greater than one. Continuing to allow access corresponds to allowing execution of the given API call);
the error message is generated and returned only when none of the predetermined number of single-action API calls have been responded to with an error message (Paragraph 77; “send an HTTP/1.1 403 error” corresponds to generating an error message in response and returning the error message to the sender because it explicitly describes sending an error back to the sender when a particular developer causes “overloading the API server 118 from a burst of API calls”, which also discloses the burst API call. Generating an error message for the API call necessarily implies that, at that particular point in time, no such error message had yet been generated for that triggering condition. Because the act of generating the error message is performed in response to detecting that condition for the first time, the prior art teaches the claimed generation of an error message when no prior error message had yet been generated for the plurality of API calls).
Kumar teaches:
detecting whether a respective error message has been returned in response to any of a predetermined number of single-action API calls from the burst that precede the given single-action API call (Paragraphs 224-229; “if there is a (e.g., non-zero) retry-after interval stored for the selected scope, the API previously returned a throttled response for that scope” (Paragraph 224), and further, “a determination may be made... whether a retry-after interval exists for any of the scopes” (Paragraph 225). The “throttled response” and “API call permission denied response” (Paragraph 229) correspond to the error message response. The act of determining whether a retry-after interval exists constitutes detecting whether an error message has been generated, because the retry-after interval is stored as a result of a prior throttled, thereby error, response. The evaluation across any of the scopes corresponds to detecting whether such an error has been generated for any of a plurality of API calls since each scope represents a set of API interactions.).
Claim 19 recites similar limitations as those of claim 12. Claim 19 is rejected for similar reasons as those of claim 12.
Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sem in view of Michels, further in view of Kumar, further in view of Garvey, further in view of Hally et al. (US 20210248007 A1) hereafter Hally.
Regarding claim 7, Sem in view of Michels, further in view of Kumar, further in view of Garvey teach the method of claim 1. Sem in view of Michels, further in view of Kumar, further in view of Garvey does not teach wherein the error message includes a Server Busy message.
However, Hally teaches:
wherein the error message includes a Server Busy message (Paragraph 16; “If the retry count limit has reached the maximum limit, then a “server busy” error message is sent to the REST API client as indicated in step 224”, where the use of a “server busy” error message explicitly discloses the Server Busy message as claimed).
Sem, Michels, Kumar, Garvey, and Hally are considered to be analogous to the claimed invention because they are in the same field of API throughput management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sem in view of Michels to incorporate the teachings of Hally and have the error message include a Server Busy message. A person of ordinary skill in the art would have recognized the use of 503 Server Busy error codes to be a known method in the art yielding the predictable result of improving UX design.
Claim 14 recites similar limitations as those of claim 7. Claim 14 is rejected for similar reasons as those of claim 7.
Claim 20 recites similar limitations as those of claim 7. Claim 20 is rejected for similar reasons as those of claim 7.
Response to Arguments
Applicant's arguments filed 12/16/2025 have been fully considered but they are not persuasive. Applicant’s arguments are summarized below:
The objection to claim 5 is overcome by the amendments set forth.
Burger does not disclose that the error return is contingent on no error having being returned in response to N API calls in a burst that immediately precede an incoming API call and therefore does not disclose or suggest the limitations as recited by amended claim 1.
Sem does not disclose the detection of whether a given task is part of a burst as recited by independent claim 8.
Sem does not disclose the recipient of an API call performing a search of a database to determine whether the API call is part of a burst as recited by amended claim 8.
As discussed in the interview, Sem does not disclose whether an incoming single-action API call is part of a plurality of similar API calls in which no two consecutive ones are delayed by more than a threshold delay, as recited by amended claim 8.
Dependent claims are submitted as allowable for at least the above reasons.
Examiner’s response:
The Examiner agrees that the previous objection to claim 5 is overcome by the amendments. Accordingly, the objection to claim 5 is withdrawn.
The Examiner agrees that Burger does not disclose the error return being contingent on no error being returned in response to N API calls in a burst immediately preceding an incoming API call. Therefore, the rejection of claim 1 under 35 U.S.C. 103 is withdrawn. However, upon further consideration in light of the amendments, a new ground(s) of rejection is made in view of Sem, Michels, Kumar, and Garvey, under 35 U.S.C. 103.
The Examiner respectfully disagrees that Sem does not disclose the detection of whether a given task is part of a burst. Sem discloses the submission of a plurality of computing tasks “near in time to one another for execution” (Col. 5, lines 40-41) and the user creates bulk task data describing the set of computing tasks which is sent to a database. Sem also notes that the API gateway or processing service is “subject to request rate limits and other possible restrictions” (Col. 5, lines 35-36). From the perspective from a person of ordinary skill in the art, a system that accepts tasks submitted near in time while handling rate-limiting, batching, and execution scheduling, must detect that the tasks are part of a set or burst in order to properly handle the incoming submissions. Without such detection, the system would be unable to apply rate limits, batching, or schedule execution properly. Therefore, the reference teaches or at least suggests the detection of whether a task is part of a burst. However, upon further consideration in light of the amendments, a new ground(s) of rejection is made in view of Sem, Michels, Kumar, and Garvey, under 35 U.S.C. 103.
The Examiner agrees that Sem does not disclose a database lookup to determine whether an API call is part of a burst as recited by amended claim 1. Therefore, the previous rejection of claim 1 under 35 U.S.C. 103 is withdrawn. However, upon further consideration in light of the amendments, a new ground(s) of rejection is made in view of Sem, Michels, Kumar, and Garvey, under 35 U.S.C. 103.
The Examiner agrees that Sem does not disclose a database lookup to determine whether an API call is part of a burst or detecting incoming single-action calls are delayed by more than a threshold delay as recited by amended claim 8. Therefore, the previous rejection of claim 1 under 35 U.S.C. 103 is withdrawn. However, upon further consideration in light of the amendments, a new ground(s) of rejection is made in view of Sem, Michels, Kumar, and Garvey, under 35 U.S.C. 103.
Independent claims 1, 8, and 15 remain rejected for the reasons stated above. Therefore, contrary to Applicant's arguments, because the dependent claims depend from an unpatentable claim and does not add limitations that overcome the rejection, it likewise remains rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Engers et al. (US 9836339 B1) discloses an API as a service that may monitor burst API processes and possibly perform throttling in response to burst API calls depending on information of the burst in a time window defined in the throttling information. (Col. 7 line 60 – Col. 8 line 6).
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 KENNETH P TRAN whose telephone number is (571)272-6926. The examiner can normally be reached M-TH 4:30 a.m. - 12:30 p.m. PT, F 4:30 a.m. - 8:30 a.m. PT, or at Kenneth.Tran@uspto.gov.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached at (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 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.
/KENNETH P TRAN/ Examiner, Art Unit 2196
/APRIL Y BLAIR/ Supervisory Patent Examiner, Art Unit 2196