DETAILED ACTION
Claims 1-20 are presented for examination.
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Claim Objections
Claims 1-7 are objected to because of the following informalities: claim 1 recites the term “the operations comprigins:”, which should be “the operations comprising:”. Appropriate correction is required.
Claims 2-7 depend on claim 1, and therefore are also objected.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 8 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 9,495,227 B2 in view of Proulx et al. (US 8,667,056 B1).
Instant application
US 9,495,227 B2
Claim 8, a method comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service;
generating a rate value for the API request;
accessing a threshold for the API request; and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold.
1. A method comprising:
receiving a REST application programming interface (API) request to a type of API resource data;
retrieving an API concurrency value for the type of API resource data;
a concurrency limit associated with the concurrency value, wherein the concurrency limit is a maximum number of API requests that are permitted to be concurrently processed by an API processing resource;
determining a comparison status associated with a comparison of the API concurrency value to a concurrency limit associated with the concurrency value; in a first condition based at least in part on if the comparison status satisfies the concurrency limit, transmitting the API request to an API processing resource; in a second condition based at least in part on if the comparison status indicates the concurrency limit is not satisfied, impeding processing of the API requested by an API processing resource.
US9495227 does not teach determining a classification for the API request based on content included in the API request, generating a rate value for the API request based on the determined classification, and accessing a threshold for the API request based on the determined classification.
However, Proulx teaches determining a classification for the API request based on content included in the API request (The Web services layer 106 can include any appropriate components known or used for receiving and managing Web service requests. These can include, for example, one or more Application Programming Interfaces (APIs), at least one Web server, firewall or security components, etc. When a request is received by the Web services layer (or another appropriate set of hardware and/or software components), the Web services layer can determine various information about the request, such as a type of request and a user, customer, or entity associated with the request; col. 3, lines 1-10), generating a rate value for the API request based on the determined classification (“a number or rate of user requests, number of users, average load, etc. and various other approaches can be utilized as well within the scope of the various embodiments. Similarly, the current rate of requests or amount of usage might be utilized”; col. 5, lines 36-39 and “r is the number of requests in the current time frame”; col. 6, lines 66-67 and “request rate”; col. 6, line 20), and accessing a threshold for the API request based on the determined classification (“T is the maximum traffic level for a particular allowance”; col. 6, line 11 and “If the user is determined to have access to the type of resource associated with the request, one or more request limits can be determined for the user 706. As discussed, the user might have an overall allowance limit on a number of requests over a given period of time, and might also have an associated burst limit for submitted requests. These limits can vary by user and/or type of resource, and further can vary over time as discussed elsewhere herein”; col. 9, lines 12-19).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Proulx to the system of US9495227 because Proulx teaches a method for dynamic throttling of requests, messages, or other such access to, or use of, resources that can be provided in a distributed environment. This dynamic throttling of requests, or "shaping" of traffic flow, can be provided by utilizing one or more resource appropriate curves or functions that are able to adapt to changing conditions across the network (abstract).
Claims 1, 8 and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 11 and 21 of U.S. Patent No. 10,467,064 B2 in view of Proulx et al. (US 8,667,056 B1).
Instant application
US 10,467,064 B2
As to claim 8, a method comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service;
generating a rate value for the API request based on the classification;
accessing a threshold for the API request based on the classification; and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold.
1. A method comprising:
receiving, from an external system associated with a first platform account on a communication platform system, a communication data application programming interface (API) request;
in response to receiving the communication data API request, determining a first data API concurrency value that indicates a number of communication data API requests being concurrently processed by an API processing resource of the platform system at a first point in time;
a data API concurrency threshold, the API concurrency threshold indicating a maximum number of communication data API requests that are permitted to be concurrently processed by the API processing resource
determining that the first data API concurrency value transgresses a data API concurrency threshold; in response to determining that the first data API concurrency value transgresses the data API concurrency threshold, delaying processing of the communication data API request; determining that the second data API concurrency value does not transgress the data API concurrency threshold; and in response to determining that the second data API concurrency value does not transgress the data API concurrency threshold, transmitting the communication data API request to the API procession resource to be processed.
As to claim 1, a system comprising:
one or more computer processors;
one or more computer memories;
a set of instructions stored in the one or more computer memories, the set of instructions configuring the one or more computer processors to perform operations, the operations comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service:
generating a rate value for the API request;
accessing a threshold for the API request; and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold.
11. A platform system comprising:
one or more computer processors; and
one or more computer-readable mediums storing instructions that, when executed by the one or more computer processors, cause the platform system to perform operations comprising:
receiving, from an external system associated with a first platform account on a communication platform system, a communication data application programming interface (API) request;
in response to receiving the communication data API request, determining a first data API concurrency value that indicates a number of communication data API requests being concurrently processed by an API processing resource of the platform system at a first point in time;
a data API concurrency threshold, the API concurrency threshold indicating a maximum number of communication data API requests that are permitted to be concurrently;
processed by the API processing resource
determining that the first data API concurrency value transgresses a data API concurrency threshold; in response to determining that the first data API concurrency value transgresses the data API concurrency threshold, delaying processing of the communication data API request
As to claim 15, a non-transitory computer-readable storage medium comprising a set of instructions that, when executed by one or more computer processors, causes the one or more computer processors to perform operations, the operations comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service:
generating a rate value for the API request;
accessing a threshold for the API request; and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold.
21. A non-transitory computer-readable medium storing instructions that, when executed by one or more computer processors of the platform system, cause the platform system to perform operations comprising:
receiving, from an external system associated with a first platform account on a communication platform system, a communication data application programming interface (API) request;
in response to receiving the communication data API request, determining a first data API concurrency value that indicates a number of communication data API requests being concurrently processed by an API processing resource of the platform system at a first point in time;
a data API concurrency threshold, the API concurrency threshold indicating a maximum number of communication data API requests that are permitted to be concurrently processed by the API processing resource;
determining that the first data API concurrency value transgresses a data API concurrency threshold; in response to determining that the first data API concurrency value transgresses the data API concurrency threshold, delaying processing of the communication data API request processed.
US10467064 does not teach determining a classification for the API request based on content included in the API request, generating a rate value for the API request based on the determined classification, and accessing a threshold for the API request based on the determined classification in claims 1, 8 and 15.
However, Proulx teaches determining a classification for the API request based on content included in the API request (The Web services layer 106 can include any appropriate components known or used for receiving and managing Web service requests. These can include, for example, one or more Application Programming Interfaces (APIs), at least one Web server, firewall or security components, etc. When a request is received by the Web services layer (or another appropriate set of hardware and/or software components), the Web services layer can determine various information about the request, such as a type of request and a user, customer, or entity associated with the request; col. 3, lines 1-10), generating a rate value for the API request based on the determined classification (“a number or rate of user requests, number of users, average load, etc. and various other approaches can be utilized as well within the scope of the various embodiments. Similarly, the current rate of requests or amount of usage might be utilized”; col. 5, lines 36-39 and “r is the number of requests in the current time frame”; col. 6, lines 66-67 and “request rate”; col. 6, line 20), and accessing a threshold for the API request based on the determined classification (“T is the maximum traffic level for a particular allowance”; col. 6, line 11 and “If the user is determined to have access to the type of resource associated with the request, one or more request limits can be determined for the user 706. As discussed, the user might have an overall allowance limit on a number of requests over a given period of time, and might also have an associated burst limit for submitted requests. These limits can vary by user and/or type of resource, and further can vary over time as discussed elsewhere herein”; col. 9, lines 12-19).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Proulx to the system of US10467064 because Proulx teaches a method for dynamic throttling of requests, messages, or other such access to, or use of, resources that can be provided in a distributed environment. This dynamic throttling of requests, or "shaping" of traffic flow, can be provided by utilizing one or more resource appropriate curves or functions that are able to adapt to changing conditions across the network (abstract).
Claims 1, 8 and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8 and 15 of U.S. Patent No. 11,093,305 B2 in view of Proulx et al. (US 8,667,056 B1).
Instant application
US 11,093,305 B2
As to claim 1, a system comprising:
one or more computer processors;
one or more computer memories;
a set of instructions stored in the one or more computer memories, the set of instructions configuring the one or more computer processors to perform operations, the operations comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service:
generating a rate value for the API request;
accessing a threshold for the API request; and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold.
8. A system comprising:
one or more computer processors; and
one or more computer-readable mediums storing instructions that, when executed by the one or more computer processors, cause the system to perform operations comprising:
receiving an application programming interface (API) request associated with a first account;
determining a first API concurrency value that indicates a number of API requests associated with the first account that are being concurrently processed by an API processing resource;
a first API concurrency threshold associated with the first account, the first API concurrency threshold indicating a maximum number of API requests associated with the first account that are permitted to be concurrently processed by the API processing resource;
determining that the first API concurrency value transgresses meets a first API concurrency threshold associated with the first account; and in response to determining that the first API concurrency value meets the first API concurrency threshold, delaying processing of the API request.
As to claim 8, a method comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service;
generating a rate value for the API request;
accessing a threshold for the API request; and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold.
1. A method comprising:
receiving an application programming interface (API) request associated with a first account;
determining a first API concurrency value that indicates a number of API requests associated with the first account that are being concurrently processed by an API processing resource;
a first API concurrency threshold associated with the first account, the first API concurrency threshold indicating a maximum number of API requests associated with the first account that are permitted to be concurrently processed by the API processing resource;
determining that the first API concurrency value meets a first API concurrency threshold associated with the first account; and in response to determining that the first API concurrency value meets the first API concurrency threshold, delaying processing of the API request.
As to claim 15, a non-transitory computer-readable storage medium comprising a set of instructions that, when executed by one or more computer processors, causes the one or more computer processors to perform operations, the operations comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service:
generating a rate value for the API request;
accessing a threshold for the API request; and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold.
15. A non-transitory computer-readable medium storing instructions that, when executed by one or more computer processors of one or more computing devices, cause the one or more computing devices to perform operations comprising:
receiving an application programming interface (API) request associated with a first account;
determining a first API concurrency value that indicates a number of API requests associated with the first account that are being concurrently processed by an API processing resource;
a first API concurrency threshold associated with the first account, the first API concurrency threshold indicating a maximum number of API requests associated with the first account that are permitted to be concurrently processed by the API processing resource;
determining that the first API concurrency value transgresses meets a first API concurrency threshold associated with the first account; and in response to determining that the first API concurrency value transgresses meets the first API concurrency threshold, delaying processing of the API request.
US11093305 does not teach determining a classification for the API request based on content included in the API request, generating a rate value for the API request based on the determined classification, and accessing a threshold for the API request based on the determined classification in claims 1, 8 and 15.
However, Proulx teaches determining a classification for the API request based on content included in the API request (The Web services layer 106 can include any appropriate components known or used for receiving and managing Web service requests. These can include, for example, one or more Application Programming Interfaces (APIs), at least one Web server, firewall or security components, etc. When a request is received by the Web services layer (or another appropriate set of hardware and/or software components), the Web services layer can determine various information about the request, such as a type of request and a user, customer, or entity associated with the request; col. 3, lines 1-10), generating a rate value for the API request based on the determined classification (“a number or rate of user requests, number of users, average load, etc. and various other approaches can be utilized as well within the scope of the various embodiments. Similarly, the current rate of requests or amount of usage might be utilized”; col. 5, lines 36-39 and “r is the number of requests in the current time frame”; col. 6, lines 66-67 and “request rate”; col. 6, line 20), and accessing a threshold for the API request based on the determined classification (“T is the maximum traffic level for a particular allowance”; col. 6, line 11 and “If the user is determined to have access to the type of resource associated with the request, one or more request limits can be determined for the user 706. As discussed, the user might have an overall allowance limit on a number of requests over a given period of time, and might also have an associated burst limit for submitted requests. These limits can vary by user and/or type of resource, and further can vary over time as discussed elsewhere herein”; col. 9, lines 12-19).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Proulx to the system of US11093305 because Proulx teaches a method for dynamic throttling of requests, messages, or other such access to, or use of, resources that can be provided in a distributed environment. This dynamic throttling of requests, or "shaping" of traffic flow, can be provided by utilizing one or more resource appropriate curves or functions that are able to adapt to changing conditions across the network (abstract).
Claims 1, 8 and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8 and 15 of U.S. Patent No. 12,020,088 B2 in view of Proulx et al. (US 8,667,056 B1).
Instant application
US 12,020,088 B2
As to claim 1, a system comprising:
one or more computer processors;
one or more computer memories;
a set of instructions stored in the one or more computer memories, the set of instructions configuring the one or more computer processors to perform operations, the operations comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service:
generating a rate value for the API request;
accessing a threshold for the API request; and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold.
8. An application programming interface (API) service comprising:
one or more computer processors; and
one or more computer-readable mediums storing instructions that, when executed by the one or more computer processors, cause the API service to perform operations comprising:
receiving an API request initiated by a first user account, the API request and directed to a first resource of the API service;
concurrent API requests directed to the first resource
determining a first concurrency limit allocated to the first user account for concurrent API requests directed to the first resource, the first concurrency limit indicating a threshold number of concurrent API requests that can be processed for the first user account; and
performing a first action based on determining that a number of received concurrent API requests initiated by the first user account meets the first concurrency limit or performing a second action based on determining that the number of received concurrent API requested initiated does not meet the first concurrency limit.
As to claim 8, a method comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service;
generating a rate value for the API request;
accessing a threshold for the API request; and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold.
1. A method comprising:
receiving, by an application programming interface (API) service, an API request initiated by a first user account, the API request directed to a first resource of the API service;
concurrent API requests directed to the first resource;
determining a first concurrency limit allocated to the first user account for concurrent API requests directed to the first resource, the first concurrency limit indicating a threshold number of concurrent API requests that can be processed for the first user account; and
performing a first action based on determining that a number of received concurrent API requests initiated by the first user account meets the first concurrency limit or performing a second action based on determining that the number of received concurrent API requested initiated does not meet the first concurrency limit.
As to claim 15, a non-transitory computer-readable storage medium comprising a set of instructions that, when executed by one or more computer processors, causes the one or more computer processors to perform operations, the operations comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service:
generating a rate value for the API request;
accessing a threshold for the API request; and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold.
15. A non-transitory computer-readable medium storing instructions that, when executed by one or more computer processors of an application programming interface (API) service, cause the API service to perform operations comprising:
receiving an API request initiated by a first user account, the API request and directed to a first resource of the API service;
concurrent API requests directed to the first resource;
determining a first concurrency limit allocated to the first user account for concurrent API requests directed to the first resource, the first concurrency limit indicating a threshold number of concurrent API requests that can be processed for the first user account; and
performing a first action based on determining that a number of received concurrent API requests initiated by the first user account meets the first concurrency limit or performing a second action based on determining that the number of received concurrent API requested initiated does not meet the first concurrency limit.
US12020088 does not teach determining a classification for the API request based on content included in the API request, generating a rate value for the API request based on the determined classification, and accessing a threshold for the API request based on the determined classification in claims 1, 8 and 15.
However, Proulx teaches determining a classification for the API request based on content included in the API request (The Web services layer 106 can include any appropriate components known or used for receiving and managing Web service requests. These can include, for example, one or more Application Programming Interfaces (APIs), at least one Web server, firewall or security components, etc. When a request is received by the Web services layer (or another appropriate set of hardware and/or software components), the Web services layer can determine various information about the request, such as a type of request and a user, customer, or entity associated with the request; col. 3, lines 1-10), generating a rate value for the API request based on the determined classification (“a number or rate of user requests, number of users, average load, etc. and various other approaches can be utilized as well within the scope of the various embodiments. Similarly, the current rate of requests or amount of usage might be utilized”; col. 5, lines 36-39 and “r is the number of requests in the current time frame”; col. 6, lines 66-67 and “request rate”; col. 6, line 20), and accessing a threshold for the API request based on the determined classification (“T is the maximum traffic level for a particular allowance”; col. 6, line 11 and “If the user is determined to have access to the type of resource associated with the request, one or more request limits can be determined for the user 706. As discussed, the user might have an overall allowance limit on a number of requests over a given period of time, and might also have an associated burst limit for submitted requests. These limits can vary by user and/or type of resource, and further can vary over time as discussed elsewhere herein”; col. 9, lines 12-19).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Proulx to the system of US12020088 because Proulx teaches a method for dynamic throttling of requests, messages, or other such access to, or use of, resources that can be provided in a distributed environment. This dynamic throttling of requests, or "shaping" of traffic flow, can be provided by utilizing one or more resource appropriate curves or functions that are able to adapt to changing conditions across the network (abstract).
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of pre-AIA 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country, more than one year prior to the date of application for patent in the United States.
Claims 1-20 is/are rejected under pre-AIA 35 U.S.C. 102(b) as being anticipated by Proulx et al. (US 8,667,056 B1).
As to claim 1, Proulx teaches a system (a system; claim 17) comprising:
one or more computer processors (a device processor; claim 17);
one or more computer memories (a memory device; claim 17);
a set of instructions stored in the one or more computer memories, the set of instructions
configuring the one or more computer processors to perform operations, the operations comprising (a memory device including instructions that, when executed by the device processor, cause the system to; claim 17):
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service (When a request is received …one or more data stores; col. 3, lines 5-20, lines 42-44 and col. 8, line 63 – col. 9, line 1);
determining a classification for the API request based on content included in the API request (The Web services layer 106 can include any appropriate components known or used for receiving and managing Web service requests. These can include, for example, one or more Application Programming Interfaces (APIs), at least one Web server, firewall or security components, etc. When a request is received by the Web services layer (or another appropriate set of hardware and/or software components), the Web services layer can determine various information about the request, such as a type of request and a user, customer, or entity associated with the request; col. 3, lines 1-10);
generating a rate value for the API request based on the classification (request rate of the resource; col. 5, line 19 – col. 6, line 22 and determines number of requests from a user for a current period; col. 9, lines 12-21);
accessing a threshold for the API request based on the classification (T is the maximum traffic level ... if the request rate exceeds T; col. 6, lines 9-22 and col. 6, line 53 – col. 7, line 5 and/or “If the user is determined … current period”, col. 9, line 12-21); and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold (“the request can be denied when the user is over a respective limit”; col 9, lines 24-25, “if the request rate exceeds T, requests to that resource might be denied as a result of the resource being determined to be unavailable for that request”; col. 6, lines 20-22, “If the request is allowed for processing … direct the request to an appropriate resource”; col. 3, lines 53-57 and “A determination is made … on to the target resource”; col. 9, lines 44-50).
As to claim 2, Proulx teaches the system of claim 1, wherein the rate value is associated with the resource, an account initiating the API request, or a combination of the resource and the account initiating the API request (“When a request is received by the Web services layer (or another appropriate set of hardware and/or software components), the Web services layer can determine various information about the request, such as a type of request and a user, customer, or entity associated with the request … In this example, a component of the Web services layer 106 might determine that the request relates to at least one resource offered by an associated provider. The resource can be any appropriate device, system, or component operable to receive a request and perform an operation in response thereto. For example, a resource might be a data server 114 operable to read, write, or process data in or from one or more data stores 116. In some embodiments, a resource might comprise one or more compute resources 118, such as may comprise a host machine or application server operable to perform a specified operation in response to a request”; col. 3, lines 5-23 and “a request is received from a user that pertains to a particular type of resource 702”; col. 8, lines 63-64).
As to claim 3, Proulx teaches the system of claim 1, wherein the rate value is based on an aggregation of request servicing measures associated with previous API requests and a predicted servicing measure associated with the API request (an example graph 500 showing a request pattern for a user over a period of time. In this example, the number of requests submitted at each time is illustrated by a first curve 502. A second curve 504 illustrates the dynamic limit on the number or rate of requests the user can submit, based at least in part upon the velocity, acceleration, and other such factors, which can increase up to a maximum allowable rate (the flat part 506 at 55 requests per frame period). Based on the number of requests submitted at each time as represented by curve 502, the actual velocity of the user can be plotted as a third curve 508 that can be calculated using any of the velocity formulas discussed or suggested herein; col. 8, lines 1-15 and Fig. 5).
As to claim 4, Proulx teaches the system of claim 1, wherein the set of actions further includes transitioning the API request to an additional resource, the additional resource having a lower priority than the resource (In some embodiments, the actual throttling can be performed by a daemon for each server in a group of managed servers capable of serving the request. In other embodiments, there may be a distributed set of daemons and/or similar components across the electronic network. As known in the art, a daemon is typically a computer program, module, or process that runs in the background on each server, rather than under the direct control of a user. In other embodiments, the throttling can be performed by an appropriate service, process, etc. After a decision is made, information for the request can be propagated to other servers in the managed group, such that each server knows the global state of the system. Thus, a requestor can at any time send a request to one of the servers, and that server will be able to know when that requestor last made a request and/or other such information; col. 10, lines 47-61. Since the other servers are selected after the target server, the other servers have lower priority compare to the target server.).
As to claim 5, Proulx teaches the system of claim 1, wherein the comparison occurs during a predetermined interval or window (the user might have an overall allowance limit on a number of requests over a given period of time, and might also have an associated burst limit for submitted requests. These limits can vary by user and/or type of resource, and further can vary over time as discussed elsewhere herein. A determination is made as to whether the user is over the allowed request limit for the current period 708; col. 9, lines 14-21).
As to claim 6, Proulx teaches the system of claim 1, wherein the set of actions comprises timing out the API request (a request will be denied until the predicted velocity falls back to within an allowable range. If the decision is made to process the request, the request can be processed; col. 9, lines 59-63).
As to claim 7, Proulx teaches the system of claim 1, wherein the set of actions comprises one of allowing, denying, or delaying processing of the API request (deny, process, delay; col. 9, lines 12-67).
As to claim 8, Proulx teaches a method (a computer-implemented method; claim 1) comprising:
receiving, by an application programming interface (API) service, an API request directed to a resource of the API service (When a request is received …one or more data stores; col. 3, lines 5-20, lines 42-44 and col. 8, line 63 – col. 9, line 1);
determining a classification for the API request based on content included in the API request (The Web services layer 106 can include any appropriate components known or used for receiving and managing Web service requests. These can include, for example, one or more Application Programming Interfaces (APIs), at least one Web server, firewall or security components, etc. When a request is received by the Web services layer (or another appropriate set of hardware and/or software components), the Web services layer can determine various information about the request, such as a type of request and a user, customer, or entity associated with the request; col. 3, lines 1-10);
generating a rate value for the API request based on the classification (request rate of the resource; col. 5, line 19 – col. 6, line 22 and determines number of requests from a user for a current period; col. 9, lines 12-21);
accessing a threshold for the API request based on the classification (T is the maximum traffic level ... if the request rate exceeds T; col. 6, lines 9-22 and col. 6, line 53 – col. 7, line 5 and/or “If the user is determined … current period”, col. 9, line 12-21); and
selecting an action to perform from a set of actions based on a comparison of the rate value to the threshold (“the request can be denied when the user is over a respective limit”; col 9, lines 24-25, “if the request rate exceeds T, requests to that resource might be denied as a result of the resource being determined to be unavailable for that request”; col. 6, lines 20-22, “If the request is allowed for processing … direct the request to an appropriate resource”; col. 3, lines 53-57 and “A determination is made … on to the target resource”; col. 9, lines 44-50).
As to claim 9, see rejection of claim 2 above.
As to claim 10, see rejection of claim 3 above.
As to claim 11, see rejection of claim 4 above.
As to claim 12, see rejection of claim 5 above.
As to claim 13, see rejection of claim 6 above.
As to claim 14, see rejection of claim 7 above.
As to claim 15, see rejection of claim 1 above.
Proulx teaches further teaches a non-transitory computer-readable storage medium comprising a set of instructions that, when executed by one or more computer processors, causes the one or more computer processors to perform operations of claim 1 above (A non-transitory computer-readable storage medium storing instructions for managing access to a shared resource, the instructions when executed by a processor causing the processor to; claim 20).
As to claim 16, see rejection of claim 2 above.
As to claim 17, see rejection of claim 3 above.
As to claim 18, see rejection of claim 4 above.
As to claim 19, see rejection of claim 5 above.
As to claim 20, see rejection of claim 6 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sadjadi (US 7,328,263 B1) teaches controlling access of concurrent users of computer resources in a distributed system using an improved semaphore counting approach.
Kumbalimutt et al. (US 2010/0229218 A1) teaches a system and method for managing requests for system resources from a plurality of users. Usage data is maintained for each user with respect to a user quota and a system quota. Aggregate system usage data is also maintained. A user request is checked for compliance with a user quota. The request is checked for compliance with a system quota. If either quota is not complied with, a hint that indicates when to send a next request is determined and sent to the user. Compliance with the system quota may include use of a reservation system, in which the allowance of a request may be based on a user's system usage data, so that a user with lower usage is more likely to have a request accepted when the system is loaded.
Dean (US 8,190,593 B1) teaches requests for resources can be throttled based on relative allocations, whereby the actual usage of a client or sub-client over time can be monitored in order to make intelligent throttling decisions. A centralized throttling service can maintain throttling information according to a hierarchical allocation tree, and can determine whether to throttle a request based at least in part whether any tokens, or available resource units, are available for a class or node of the tree corresponding to the request. In some cases, an empty token bucket for a node can borrow tokens from a parent node, in order to allow a user to exceed an allocation when the capacity of the system allows for such usage. When a user has been exceeding an allocation or otherwise inappropriately taxing various resources, the system can prevent that user from borrowing tokens for at least a specified period of time.
Gibson (US 8,681,630 B1) teaches a system disclosed rate limits API requests. The system includes an API server that receives an API request from a developer application at an API server and a token bucket to rate limit API requests from the developer application. A token query translation module determines a number of tokens needed to process the API request based on a rate configured in predefined policy data for the developer application and a replenish rate of the token bucket. The number of tokens inversely corresponds to the rate configured in the predefined policy data. A token request module instructs the API server to process the API request if the token bucket has sufficient tokens and reduces the number of tokens in the token bucket for the developer application by the number of tokens needed to process the API request.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIEM K CAO whose telephone number is (571)272-3760. The examiner can normally be reached Monday-Friday 8:00am-4:00pm.
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.
/DIEM K CAO/Primary Examiner, Art Unit 2196
DC
August 10, 2026
Prosecution Insights