Prosecution Insights
Last updated: April 19, 2026
Application No. 18/651,611

ADAPTIVE THROTTLING OF STORAGE SERVICE TRAFFIC WITHIN A CLIENT APPLICATION

Non-Final OA §102§103
Filed
Apr 30, 2024
Examiner
GEORGANDELLIS, ANDREW C
Art Unit
2459
Tech Center
2400 — Computer Networks
Assignee
Oracle International Corporation
OA Round
1 (Non-Final)
56%
Grant Probability
Moderate
1-2
OA Rounds
4y 0m
To Grant
96%
With Interview

Examiner Intelligence

Grants 56% of resolved cases
56%
Career Allow Rate
274 granted / 490 resolved
-2.1% vs TC avg
Strong +40% interview lift
Without
With
+40.4%
Interview Lift
resolved cases with interview
Typical timeline
4y 0m
Avg Prosecution
18 currently pending
Career history
508
Total Applications
across all art units

Statute-Specific Performance

§101
0.8%
-39.2% vs TC avg
§103
84.3%
+44.3% vs TC avg
§102
6.0%
-34.0% vs TC avg
§112
3.1%
-36.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 490 resolved cases

Office Action

§102 §103
DETAILED ACTION Introduction Claims 1-20 are pending. This Office action is in response to Application 18/661,611 filed on 4/30/2024. Other Prior Art Mueller (US 2012/0239814) teaches accessing a cloud storage provider by a cluster. See par. 10; fig. 4. Claim Rejections: 35 U.S.C. 102 The following is a quotation of the appropriate paragraphs of 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 – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention. Claims 1-3, 8-10, and 15-17 are rejected under 35 U.S.C. 102(a)(1) because they are anticipated by Rajagopalan (US 2022/0247686). Regarding claims 1, 8, and 15, Rajagopalan teaches a computer-implemented method to manage access request frequency to resources with dynamically varying available capacity, comprising: maintaining a computing cluster that accesses a storage service (The system intercepts application protocol interface (API) calls from client devices to a cloud service and intercepts responses from the cloud service to the client devices. Therefore, the system may be said to be accessing the cloud service. See par. 48, 159. The system may be implemented by a cluster. See par. 52. The cloud service is understood to be any type of cloud service, including a cloud storage service. See par. 62), wherein the storage service has limited capacity to service requests, and the limited capacity is shared among a plurality of clients that access the storage service (The cloud storage service can become overloaded due to excessive API calls from the clients. See par. 129-130); monitor requests submitted to the storage service (The system monitors a rate of API calls to the cloud storage service as well as the rate of API events generated for the API calls forwarded to the cloud storage service. See par. 127; fig. 11, step 1120); and adaptively throttling requests to the storage service based on success or failure rates of the monitored requests submitted to the storage service (The system infers load conditions of the cloud storage service by comparing the rate of API events generated for the API calls made to the cloud storage service against the rate of responses from the cloud storage service indicating either a successful status or an imposition of a throttling penalty by the cloud storage service. See par. 135; fig. 11, step 1140. The system adjusts a rate of throttling API calls to the cloud storage service based on the inferred load conditions. See par. 142; fig. 11, step 1150). Regarding claims 2, 9, and 16, Rajagopalan teaches the computer-implemented method of claim 1, wherein the plurality of clients in aggregate can send more requests to the storage service than the storage service can process at any given time (The cloud storage service can receive more traffic than it can handle, thereby causing it to become overloaded. See par. 130). Regarding claims 3, 10, and 17, Rajagopalan teaches the computer-implemented method of claim 1, wherein the storage service does not enforce a limit on a rate of requests a client can send to the storage service and does not reserve capacity for processing the same number of requests (Rajagopalan suggests that it is strongly desired to perform both client-side throttling and server-side throttling at the cloud storage service. See par. 21. However, the method of Rajagopalan does not require the cloud storage service to perform throttling because it can adapt client-side throttling based on the rate of HTTP 429 response status codes (i.e., too many requests) received from the cloud storage service, regardless of whether the cloud storage service imposes throttling. See par. 109, 111, and 132). Claim Rejections: 35 U.S.C. 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 4-6, 11-13, and 18-20 are rejected under 35 U.S.C. 103 because they are unpatentable over Rajagopalan, as applied to claims 1, 8, and 15 above, in further view of Chen (US 2020/0028788). Regarding claims 4, 11, and 18, Rajagopalan does not teach the computer-implemented method of claim 1, wherein the available capacity is determined for each container on the storage service. However, Chen teaches a method for rate limiting requests to instances (each of which may be implemented as a virtual machine or container. See par. 45, 47) of a cloud service, whereby each container is assigned a rate limit based on a corresponding capacity of the container. See par. 9-10; fig. 3B. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the system of Rajagopalan so that the system infers the load condition of each container of the cloud storage service, because doing so allows the system to determine a throttle rate for each container of the cloud storage service when the cloud storage service comprises multiple containers. Regarding claims 5, 12, and 19, Rajagopalan teaches the computer-implemented method of claim 1, wherein the computing cluster comprises a plurality of nodes, and one or more nodes determine an available capacity for the storage service to process requests (As indicated in the discussion of claim 1, Rajagopalan teaches that the system may be implemented by a cluster of nodes, which implies that at least one of the nodes of the cluster performs the function of inferring the load condition of the cloud service which is described at par. 135 and fig. 11, step 1140), but does not teach that the available capacity is for the storage service to process requests to each container of one or more containers accessed by the one or more nodes. Nonetheless, Chen teaches a method for rate limiting requests to instances (each of which may be implemented as a virtual machine or container. See par. 45, 47) of a cloud service, whereby each container is assigned a rate limit based on a corresponding capacity of the container. See par. 9-10; fig. 3B. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Rajagopalan so that a node of the cluster infers the load conditions of each container of the cloud storage service, because doing so allows the system to determine a throttle rate for each container of the cloud storage service when the cloud storage service comprises multiple containers. Regarding claims 6, 13, and 20, Rajagopalan and Chen teach the computer-implemented method of claim 5, wherein the computing cluster accesses multiple containers at the storage service and requests sent to the storage service are separately throttled for each container (Chen teaches a cloud service comprising multiple containers. See par. 9-10; fig. 3B. Thus, Chen suggests further modifying the system of Rajagopalan and Chen so that accessing the cloud storage service by the system comprises accessing a plurality of containers of the cloud storage service, and the system throttles API calls separately for each container, because doing so is beneficial for the reasons provided above with respect to claim 5). Claims 7 and 14 are rejected under 35 U.S.C. 103 because they are unpatentable over Rajagopalan, as applied to claims 1 and 8 above, in further view of Hallisey (US 2018/0018116). Regarding claims 7 and 14, Rajagopalan does not teach the computer-implemented method of claim 1, wherein the computing cluster uses a first container on the storage service for replication and disaster recovery operations and a second container on the storage service is used by a customer to load customer data. However, Hallisey teaches a system for containerizing a block storage service whereby the block storage service uses a backup component on a first container for backup and recovery service, and whereby the block storage service uses an API component on a second container for storing data to the block storage service. See par. 28-30. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Rajagopalan so that the cluster uses a backup and recovery function on a first container and an API component on a second container of the cloud storage service, because compartmentalizing components of the cloud storage service in different containers eliminates dependence among the components and facilitates upgrading of the components, according to Hallisey. See par. 20. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andrew Georgandellis whose telephone number is 571-270-3991. The examiner can normally be reached on Monday through Friday, 7:30-5:00 PM EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tonia Dollinger, can be reached on 571-272-4170. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /ANDREW C GEORGANDELLIS/Primary Examiner, Art Unit 2459
Read full office action

Prosecution Timeline

Apr 30, 2024
Application Filed
Jan 12, 2026
Non-Final Rejection — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12574425
SYSTEMS AND METHODS FOR APPLICATION OF CONTEXT-BASED POLICIES TO VIDEO COMMUNICATION CONTENT
2y 5m to grant Granted Mar 10, 2026
Patent 12549510
METHODS AND SYSTEMS FOR ACCESSING CONTENT
2y 5m to grant Granted Feb 10, 2026
Patent 12526335
NONSTOP VIRTUAL REMOTE DIRECT MEMORY ACCESS
2y 5m to grant Granted Jan 13, 2026
Patent 12493537
SYSTEM AND METHOD FOR BOOTING SERVERS IN A DISTRIBUTED STORAGE TO IMPROVE FAULT TOLERANCE
2y 5m to grant Granted Dec 09, 2025
Patent 12476870
DATA COLLECTION METHOD AND DEVICE
2y 5m to grant Granted Nov 18, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
56%
Grant Probability
96%
With Interview (+40.4%)
4y 0m
Median Time to Grant
Low
PTA Risk
Based on 490 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month