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 are presented for the examination.
The cross reference related to the application cited in the specification must be updated (i.e. update the relevant status, with PTO serial numbers or patent numbers where appropriate, on para[0002]). The specification should be so revised.
§ 101 2. 35 U.S.C. 101 reads as follows
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 2 , 3, 4, 5, 6, 7, 10, 12, 13, 14, 15, 16, 17, 18, 19, 21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As to Claims 2, 12, 13 have been rejected under 35 USC 101 for abstract idea without significantly more. Under Step 2A, Prong 1, the “ identifying, by the one or more processors, one or more entities ”, “ determining, by the one or more processors, an expected API limit”, recite a mental process since “determining” and “identifying” are functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgment, opinion.
Under Prong 2, the additional element “ a request to modify an application programming interface (API) limit for an entity to a target API limit, modifying, by the one or more processors, based on the expected API limit for entity, the API limit for the entity to the target API limit” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception, Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
Under Step 2B, the additional elements “ a request to modify an application programming interface (API) limit for an entity to a target API limit” - this generally have been a mental process although the application programming interface could be a generic computer component if the spec describes it as actual computer software in computer hardware.
“modifying, by the one or more processors, based on the expected API limit for entity, the API limit for the entity to the target API limit” - this is mere instructions to apply the mental process under mpep 2106.05(f), amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
As to Claims 3, 4, 5, 6, 7, 10, 14, 15, 16, 17, 18, 19, 21 have been rejected under 35 USC 101 for abstract idea without significantly more. Under Step 2A, Prong 1, the “ identifying, by the one or more processors, one or more entities ”, “ determining, by the one or more processors, an expected API limit”, “determining, by the one or more processors, a value of an attribute describing a received API request for the entity”, “ indicates a number of API requests processed for the entity in a time interval of a particular size and wherein the modified API limit specifies a maximum number of API requests processed for the entity in the time interval of the particular size” , “ indicates a number of envelopes sent by the entity in a time interval of a particular size and wherein the modified API limit specifies a maximum number of envelopes allowed to be sent by the entity in any time interval of the particular size”, “ indicates a number of documents allowed in an envelope sent by the entity in an API request of a particular type and wherein the modified API limit specifies a maximum number of documents allowed to be sent by the entity in any API request of the particular type”, “ identifying the one or more entities comprises:extracting a set of features describing past API requests received from the entity; and comparing the set of features extracted from the entity with corresponding features extracted from each of the one or more entities” , “ determining a type of system for the entity, wherein the type of system is one of an embedded application or a system integration, wherein identifying the one or more entities is further based on the type of system.” ; recite a mental process since “determining”, “identifying”, “ indicating” and “ specifying” are functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgment, opinion.
Under Prong 2, the additional element “ a request to modify an application programming interface (API) limit for an entity to a target API limit, modifying, by the one or more processors, based on the expected API limit for entity, the API limit for the entity to the target API limit, executing, by the one or more processors, an operation corresponding to the received API request based on the value of the attribute being within the modified API limit.” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception, Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
Under Step 2B, the additional elements “ a request to modify an application programming interface (API) limit for an entity to a target API limit” - this generally have been a mental process although the application programming interface could be a generic computer component if the spec describes it as actual computer software in computer hardware.
“modifying, by the one or more processors, based on the expected API limit for entity, the API limit for the entity to the target API limit, executing, by the one or more processors, an operation corresponding to the received API request based on the value of the attribute being within the modified API limit.” - this is mere instructions to apply the mental process under mpep 2106.05(f), amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application. See MPEP 2106.05(d). Thus, the claim is not patent eligible.
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).
he 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.
Claims 2-21 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-12 of U.S. Patent No. US 12033007 B2 . Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-12 of US Patent US 12033007 B2 contain(s) every element of claim(s) 2-21 of the instant application and thus anticipate the claim(s) of the instant application.
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.
Claim(s) 2, 12, 13 are rejected under 35 U.S.C. 103 as being unpatentable over Thompson( US 9942354 B1) in view of Luff( US 9405597 B1).
As to Claim 2, Thompson teaches receiving, by one or more processors, a request to modify an application programming interface (API) limit for an entity to a target API limit( The computing device 810 may include one or more processors 812 that are in communication with memory devices 820, col 15, ln 62-67/ Feedback may be provided to one or more sending services in the group of sending services according to the comparison, and a request may be made to the sending service(s) to adjust the current rate of service message requests (e.g., to request a decrease or possibly an increase) sent to the receiving service from the one or more sending services. In one aspect, the feedback may be used in order to throttle up and/or throttle down the current rate of service message requests sent to the receiving service from the one or more services, col 2, ln 25-39/ The sending services 130 may be a group of services, such as a group of federated services. Each sending service 130 may also include a throttle module 135 for throttling up and/or throttling down a number of service message requests (e.g., API calls) sent to the receiving service 110 or other sending services 130, col 3, ln 8-15/ the receiving service 110 cannot process that many messages at a time, then the receiving service can send an upstream throttling message, through a throttling communication channel to ask one or more sending services to send fewer messages, col 4, ln 7-12),
identifying, by the one or more processors, one or more entities based on one or more API requests received from the one or more entities( As such, the back pressure throttle module 375 may indicate to service 330b to throttle down a number of service message requests sent to service 330c. Alternatively, the monitoring service 310 may determine that the current rate of service message for the service 330b is less than the allowable rate of service message. As such, the back pressure throttle module 375 may indicate to service 330a and/or service 330c to throttle up the number of service message requests sent to service 330b, col 11, ln 35-46)
determining, by the one or more processors, an expected API limit for the entity based on respective API limits of the one or more entities( defining an allowable rate of service message requests, such as API calls, to be received at the receiving service from one or more other services, such as a group of federated services, executing in a computing service environment, col 2, ln 10-15/ the allowable rate of service message requests can be defined as K number of service message request (e.g., API calls) per second per a selected period of time, where K is a positive integer. If more than K messages per second are received at the receiving service 110 and the receiving service 110, col 4, ln 2-10)
and modifying, by the one or more processors, based on the expected API limit for entity, the API limit for the entity to the target API limit( The current rate of service message requests may be compared to the allowable rate of service message requests for the receiving service. Feedback may be provided to one or more sending services in the group of sending services according to the comparison, and a request may be made to the sending service(s) to adjust the current rate of service message requests (e.g., to request a decrease or possibly an increase) sent to the receiving service from the one or more sending services. In one aspect, the feedback may be used in order to throttle up and/or throttle down the current rate of service message requests sent to the receiving service from the one or more services, col 2, ln 25-39/ The current rate of service message requests may be compared to the allowable rate of API service message requests, as in block 530. A message may be sent to a one or more services from the group of services, according to the comparison to adjust service message requests sent to the API gateway from the one or more services, as in block 540, col 13., ln 50-60/ the receiving service 110 cannot process that many messages at a time, then the receiving service can send an upstream throttling message, through a throttling communication channel to ask one or more sending services to send fewer messages, col 4, ln 7-12).
Luff teaches determining, by the one or more processors, an expected API limit for the entity based on respective API limits of the one or more entities, modifying, by the one or more processors, based on the expected API limit for entity, the API limit for the entity to the target API limit( establish a limit on the rate at which an external account's applications may make calls to the API's data, for example to prevent malicious or unintentional over-use of the resources of the social network API. If this rate limit is exceeded, the social network typically will restrict the rate at which the account can make further API calls for a period of time, prevent the types of API calls available to the account, or impose other limits on API use by the same account, col 1, ln 14-25/ APIs may have rate limits or quotas that are imposed by the source system 110. Rate limits may specify how many calls an external application may make within a specified period of time, referred to as a rate window, to the data or processes controlled by an API, col 3, ln 7-14/ The throttling service may also periodically request current rate limit policy updates from a source system such as system 110, and employ these updates as a basis for adjusting the token generation rate. For example, if the source system returns a rate limit policy update that reduces the number of API calls allowed from 100 to 80 API calls per hour, and the current token generation rate is 75 API calls per hour, then the throttling service may reduce the token generation rate by a value, such as 33%, to 50 API calls per hour in order to prevent a rate limit error. In addition, a token generation rate may be increased. For example if the source system returns a rate limit policy that is 80 API calls per hour and the current token generation rate is at a value less than 80, such as 50% less, then the token generation rate may be increased to a value, such as 80% of the rate limit policy, or 64 API calls per hour, col 3, ln 50-65).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Thompson with Luff to incorporate the above feature because this prevents malicious or unintentional over-use of the resources of the social network API and prevents the types of API calls available to the account, or imposes other limits on API use by the same account.
As to claims 12, 13, they are rejected for the same reason as to claim 2 above. In additional, Thompson teaches non-transitory computer-readable storage media( non-transitory machine-readable storage medium, col 13, ln 45-47).
Claim(s) 3, 4, 5, 6, 14, 15, 16, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Thompson( US 9942354 B1) in view of Luff( US 9405597 B1) and further in view of KIMURA( US 20170262628 A1).
As to Claim 3, Thompson teaches after modifying the API limit: determining, by the one or more processors, a value of an attribute describing a received API request for the entity( col 7, ln 30-52).
Kimura teaches executing, by the one or more processors, an operation corresponding to the received API request based on the value of the attribute being within the modified API limit( On the other hand, when the request-acceptance-propriety determination unit 236 determines that the number of times of access in a unit time has not reached the rate limit (NO at Step S13), the request-acceptance-propriety determination unit 236 increments the number of times of access to the API key in the access-number management table 226 (Step S15). Subsequently, the request-acceptance-propriety determination unit 236 performs a request process using the API handler 11 (Step S16), para[0125]).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Thompson and Luff with Kimura to incorporate the above feature because this improves the convenience and safety of providing APIs.
As to Claim 4, Luff teaches the value of the attribute indicates a number of API requests processed for the entity in a time interval of a particular size and wherein the modified API limit specifies a maximum number of API requests processed for the entity in the time interval of the particular size( col 5, ln 50-67/ col 3, ln 45-65) for the same reason as to claim 3 above.
As to claim 14, 15, they are rejected for the same reason as to claims 5, 6 above.
Claim(s) 5, 6, 14, 15, 16, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Thompson( US 9942354 B1) in view of Luff( US 9405597 B1) in view of KIMURA( US 20170262628 A1) and further in view of Xiao( US 8953453 B1).
As to Claim 5, Luff teaches the value of the attribute indicates a number of envelopes sent by the entity in a time interval of a particular size and wherein the modified API limit specifies a maximum number of envelopes allowed to be sent by the entity in any time interval of the particular size col 5, ln 50-67/ col 3, ln 45-65) for the same reason as to claim 3 above.
Xiao teaches specifies a maximum number of envelopes ( FIG. 1, the clients 105 may encompass any type of clients configured to submit service requests to Web server 130 via network 110 on behalf of a user or a requesting application. For example, a given client 105 may include a suitable version of a Web browser, or a plug-in module or other type of code module configured to execute as an extension to or within an execution environment provided by a Web browser. Alternatively, a client 105 may encompass an application such as a database application, media application, office application, or any other application that may make use of the services provided by Web server 130. In some embodiments, such an application may include sufficient protocol support (e.g., for a suitable version of Hypertext Transfer Protocol (HTTP)) for generating and processing Web service requests without necessarily implementing full browser support for all types of Web-based data. That is, client 105 may be an application configured to interact directly with Web server 130. In various embodiments, client 105 may be configured to generate requests for Web services according to a Representational State Transfer (REST)-style Web services architecture, a document or message-based Web services, col 4, ln 40-67/ perform throttling and otherwise managing service requests that have non-uniform workloads by adjusting a maximum request rate dependent on a current work throughput rate. For example, in some embodiments the amount of work required to satisfy various service requests is non-uniform (e.g., the amount of work required to satisfy service requests may vary based on the type of request, the state of the targeted resources, or the specific results of the requested operation), col 8, ln 36-46).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Thompson, Luff and Kimura with Xiao to incorporate the above feature because this provides Common solutions applied by overloaded systems include denying service to clients or throttling a certain number of incoming requests until the systems get out of an overloaded state.
As to Claim 6, Xiao teaches the value of the attribute indicates a number of documents allowed in an envelope sent by the entity in an API request of a particular type and wherein the modified API limit specifies a maximum number of documents allowed to be sent by the entity in any API request of the particular type (col 4, ln 40-67) for the same reason as to claim 5 above.
As to claims 16, 17, they are rejected for the same reason as to claims 5, 6 above.
Claim(s) 7, 8, 18, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Thompson( US 9942354 B1) in view of Luff( US 9405597 B1) and further in view of Rudeanu(US 11233802 B1).
As to Claim 7, Rudeanu teaches identifying the one or more entities comprises: extracting a set of features describing past API requests received from the entity; and comparing the set of features extracted from the entity with corresponding features extracted from each of the one or more entities(the web server is able to analyze the most recent data about the client in comparison to historical information about the same client. The more recent data is compared against the historical information it has about the client to determine whether the client is potentially a malicious entity. To determine whether the number of requests is indeed an anomaly, the security check may compare the number of requests to a number of requests that was previously recorded and logged for the client for an indication on the amount of differences between them, col 3, ln 59-67).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Thompson, Luff with Rudeanu to incorporate the above feature because this prevents session theft and otherwise maintaining high levels of security involves significant effort and resources.
As to Claim 8, Rudeanu teaches the set of features comprises one or more features representing: a rate at which API requests were received from the entity in a time interval; a type of API identified in the request to modify the API limit; or one or more parameters passed with a previous API request from the entity( col 3, ln 28-40) for the same reason as to claim 7 above.
As to claim 18, 19, they are rejected for the same reasons as to claims 7, 8 above.
Claim(s) 9, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Thompson( US 9942354 B1) in view of Luff( US 9405597 B1) and further in view of Beecham(US 20180307857 A1).
As to Claim 9, Beecham teaches determining the expected API limit for the entity comprises:extracting a set of features describing past API requests received from the entity; providing the set of features as input to a machine learning model trained for a category of entity representing the one or more entities; and executing the machine learning model to predict the expected API limit for the entity( In some embodiments, the risk metric may be an amount of access requests received within a trailing duration of time, a total amount of access requests, or combination thereof. In some embodiments, the risk metric is based on deviation from previous patterns of behavior. For example, some embodiments may train a machine learning algorithm, such as a hidden Markov model, recurrent neural network, or the like, based on historical log events, to predict the likelihood of various types of access requests (or sequences of such requests), such as to particular units of content, types of unit of content, amounts of access requests, frequencies of access requests, or the like, for a given user, workload application, computing device, portion of a network, or combination thereof. Some embodiments may then compare these predictions based on a current trailing sequence of logged events with later received access requests and determine a risk metric based on the likelihood, for example, a probability of the given access requests given previous behavior. Failures of such predictive models may be evidence of anomalous, malicious behavior. Some embodiments may use this probability is a risk metric or determine an aggregate of these probabilities over a plurality of risk metrics, such as a measure of central tendency, like a mean, median, or mode of these probabilities over a trailing duration or number of access requests, para[0245], ln 10-40).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Thompson, Luff with Beecham to incorporate the above feature because this facilitates relatively fast access to content of nodes.
As to claim 20, it is rejected for the same reason as to claim 9 above.
Claim(s) 10, 21 are rejected under 35 U.S.C. 103 as being unpatentable over Thompson( US 9942354 B1) in view of Luff( US 9405597 B1) and further in view of POITREY(US 20180365190 A1).
As to Claim 10, POITREY teaches determining a type of system for the entity, wherein the type of system is one of an embedded application or a system integration, wherein identifying the one or more entities is further based on the type of system( In response to a steering request from the client 304, the selection engine 316 selects one of the API edge gateways 302 for processing the API call. In particular, the selection engine 316 routes the client 304 to one of the embedded acceleration systems 320, one of the IX acceleration systems 322, or the API processing system 102., para[0042], ln 1-10/ With respect to the reachability criteria, the mapping engine 312 maps a set of clients to only those acceleration systems 320 or 322 that are accessible by those clients. As discussed above, because an embedded acceleration system 320 is internal to an ISP, the embedded acceleration system 320 is accessible only by clients that are associated with and/or subscribe to the ISP. Therefore, the mapping engine 312 maps a set of clients to a given embedded acceleration system 320 only when the set of clients is associated with and/or subscribes to the ISP within which that embedded acceleration system 320 is embedded. Similarly, because an IX acceleration system 322 is internal to an Internet exchange point, the IX acceleration system 322 is accessible only by clients that can access that Internet exchange point., para[0034], ln 1-17).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Thompson, Luff with POITREY to incorporate the above feature because this facilitates the processing of application programming interface (API) calls.
As to claim 21, it is rejected for the same reason as to claim 10 above.
Claim(s) 11 is rejected under 35 U.S.C. 103 as being unpatentable over Thompson( US 9942354 B1) in view of Luff( US 9405597 B1) and further in view of Vegesna(US 20120173612 A1).
As to Claim 11, Vegesna teaches the one or more API requests include a request to perform an operation comprising one or more of: modifying a document; executing a document; or sending an envelope comprising a set of documents to another entity( he document editing application server 106 includes a server-side remote API 116, server-side application logic 118, and a document cache 120. The client-side remote API 114 at the unhosted third party application client 104 location works with the server-side remote API 116 at the document editing application server 106 location to give the third party application access to the remote application server., para[0036], ln 1-9/ In block 304, the request to open is sent from the client side API, whose implementation is integrated as a module into the third party application. The request is sent through the Internet, in block 306, to the module that implements the server side API, which is integrated with the remote server that implements the logic to edit documents, para[0060], ln 10-21).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Thompson, Luff with Vegesna to incorporate the above feature because this providesevolution of the document editing application takes advantage of the cloud computing paradigm that eliminates the need (for the user) to own and maintain application software.
Conclusion
US 9942354 B1 teaches allowable rate of API service message requests. A message may be sent to the one or more services from the group of services, according to the comparison, to adjust service message requests sent to the first service from the one or more services.
US 9405597 B1 teaches and employ these updates as a basis for adjusting the token generation rate. For example, if the source system returns a rate limit policy update that reduces the number of API calls allowed from 100 to 80 API calls per hour, and the current token generation rate is 75 API calls per hour, then the throttling service may reduce the token generation rate by a value, such as 33%, to 50 API calls per hour in order to prevent a rate limit error. In addition, a token generation rate may be increased. For example if the source system returns a rate limit policy that is 80 API calls per hour and the current token generation rate is at a va.
US 20170262628 A1 teaches the rate-limit calculation unit 235 increases and decreases the rate limit according to increase and decrease of the stability calculated by the stability calculation unit 234. Specifically, the rate-limit calculation unit 235 increases the value of the rate limit when the value of the stability calculated by the stability calculation unit 234 increases. On the other hand, the rate-limit calculation unit 235 decreases the value of the rate limit when the value of the stability calculated by the stability calculation unit 234 decreases. Alternatively, the rate-limit calculation unit 235 increases the value of the rate limit when the value of the stability calculated by the stability calculation unit 234 has exceeded a predetermined threshold
US 20220247686 A1 teaches SaaS server to adjust request patterns on client side for remediating throughput penalties. In one implementation, the algorithm sets the API call throttle limit dynamically adapted to the inferred load conditions which vary over time. In one implementation, the API call throttle limit is set to adjust the rate of the service requests. In other implementations, the throttle limit set to adjust the rate of API calls for the requests.
US 20180167288 A1 teaches PI throttling to prevent the API execution count from exceeding the API-execution-count limiting value and prevent a large surplus of the API execution count even when the number of the virtual servers 302 is changed by the auto scaling.
US 10445151 B1 teaches various embodiments, an agent executing at the recipient edge server will query master counter service 102 for updates to the statuses of API service counter identifiers, which would include which API service counter identifiers should be blocked from further API request servicing, prior to servicing a received API request. After an API request has been serviced by the edge server, the agent executing at the edge server is
US 20230298027 A1 teaches which data is preloaded in requests to minimize the number of API calls needed and to increase efficiency, as described above.
US 6161152 teaches Aubsequent requests to open files causes the I/O proxy process to close at least one of the open files to free a file descriptor. Opening and closing files increases the number of system calls and each of these system calls typically uses a context switch. Any inquiry concerning this communication or earlier communications from the examiner should be directed to LECHI TRUONG whose telephone number is (571)272-3767. The examiner can normally be reached 10-8 PM.
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 Young Kevin can be reached on (571)270-3180. 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.
/LECHI TRUONG/Primary Examiner, Art Unit 2194
Prosecution Insights