DETAILED ACTION
Status of the Claims
Claims 1–20 are pending. Claims 1, 4–8, 11, 13–15, 18, and 20 have been amended, no claims have been canceled, withdrawn, or objected to, and no claims are allowable. Claims 1–20 are rejected under 35 U.S.C. § 103, as set forth below. As an alternate ground, claims 6, 13, and 20 are additionally rejected under 35 U.S.C. § 103 as set forth below.
Other Prior Art
Dean (US 8,190,593 B1) discloses throttling requests for resources based on relative allocations, whereby the actual usage of a client or sub-client over time is monitored to make throttling decisions and a centralized throttling service determines whether to throttle a request based at least in part on whether tokens are available for the class of node corresponding to the request (Abstract).
Aggarwal et al. (US 12,182,623 B1) discloses detecting that a service receiving task requests associated with clients or profiles is under duress based on performance information, and, responsive to the duress, selecting a profile based on its respective volume of requests and applying a task request limit to that profile until the service is no longer under duress (Abstract).
Harjono et al. (US 12,217,088 B2) discloses optimizing usage of computing resources in a data system by dynamic throttling performed locally on a computing resource in the foreground and autoscaling performed in a centralized fashion in the background, the dynamic throttling lowering the load without overshooting while reducing the throttle quickly (Abstract).
Response to Arguments
The arguments of Applicant’s representative filed April 28, 2026 have been fully considered.
Rejection of Claims 1, 8, and 15 under 35 U.S.C. § 102 over Rajagopalan.
Applicant’s representative amended independent claims 1, 8, and 15 to recite monitoring requests submitted to the storage service to determine success or failure rates of the monitored requests, wherein a first subset of the requests is directed to a first storage and a second subset is directed to a second storage, and adaptively throttling requests to the first and second storage based on the success or failure rates of the respective subsets. Applicant’s representative argues that the amendments overcome the rejection because Rajagopalan does not teach the amended limitations. Examiner agrees. Nonetheless, Swift in view of Zelek teaches amended claim 1, as discussed in the rejection below.
Rejection of Claims 4–6, 11–13, and 18–20 under 35 U.S.C. § 103 over Rajagopalan and Chen.
Applicant’s representative argues that these claims overcome the art for the reasons given as to the first claim in the chain. However, this argument is not persuasive for the reasons provided above with respect to claim 1.
Rejection of Claims 7 and 14 under 35 U.S.C. § 103 over Rajagopalan and Hallisey.
Applicant’s representative argues that these claims overcome the art for the reasons given as to the first claim in the chain. However, this argument is not persuasive for the reasons provided above with respect to claim 1.
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 1–3, 8–10, and 15–17 are rejected under 35 U.S.C. § 103 as being unpatentable over the non-patent literature entitled “Rate Limiting” of the OpenStack Swift documentation (“Swift”) in further view of Zelek et al. (US 9,705,733 B2; “Zelek”).
Regarding claims 1, 8, and 15, Swift 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,
Swift teaches maintaining a computing cluster that accesses a storage service, in that requests from the cluster are directed to the storage service at the container path /account/container/object of the storage service (pg. 1, lines 22–26).
wherein the storage service has limited capacity to service requests,
Swift teaches that the storage service has a limited capacity to service requests, in that a container has a finite request-per-second capacity that is rate-limited to prevent the “many writes to a single container” bottleneck (pg. 2, lines 5–9).
the limited capacity is shared among a plurality of clients that access the storage service;
Swift teaches that the limited capacity is shared among a plurality of clients (accounts) that access the storage service, in that a single account may use too much of the cluster’s resources, for which a per-account global write ratelimit is provided in addition to the container limits (pg. 2, lines 5–12).
wherein a first subset of the requests is directed to a first storage and a second subset of the requests is directed to a second storage,
Swift teaches that requests are directed to a particular container identified in the request path (/account/container/object), such that a first subset of the requests directed to a first container and a second subset of the requests directed to a second container are each rate-limited per container (pg. 1, lines 22–26).
the first storage and the second storage each comprise a storage container or bucket formed from one or more storage devices of the storage service;
Swift teaches that each such storage is a container of the object storage cluster, the rate limiting being performed on requests that result in database writes to the account and container databases (pg. 1, lines 5–6). A container of a distributed object store necessarily stores its object data on one or more physical storage devices of the cluster, as a container cannot persist object data without underlying storage devices; each container is therefore inherently formed from one or more storage devices of the storage service.
However, Swift does not expressly teach monitoring requests submitted to the storage service to determine success or failure rates of the monitored requests, … adaptively throttling requests to the first and second storage of the storage service, wherein the requests to the first storage of the storage service are throttled based on success or failure rates of the first subset of the monitored requests submitted to the storage service, and the requests to the second storage of the storage service are throttled based on success or failure rates of the second subset of the monitored requests submitted to the storage service, insofar as Swift limits requests against a configured per-container rate rather than monitoring the success or failure rates of the requests. Nonetheless, Zelek teaches determining whether each sent request is successfully received, storing the result on a per-agent basis, and maintaining a success rate for each agent device from that agent device’s successful and total requests (col. 4, lines 38–55); Zelek adaptively throttles requests by adjusting, for each target and based on the success rate maintained for that target, a metric related to a sent request and a subsequently sent request to that target, increasing the time between requests or decreasing the number of subsequently sent requests to that target when the success rate for that target falls below a threshold (col. 5, lines 6–27; col. 7, lines 11–25; fig. 2B); and, applying that per-target, success-rate-based throttling to each of Swift’s independently throttled containers (pg. 1, lines 24–26) throttles the requests to the first storage based on the success or failure rates of the first subset and the requests to the second storage based on those of the second subset.
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 method of Swift so that the requests submitted to the storage service are monitored to determine the success or failure rates of the monitored requests and the requests to each of the first and second storage are adaptively throttled based on the success or failure rates of the subset of requests directed to that storage, as taught by Zelek, because doing so identifies when requests are failing due to overload and governs each container by the success rate of the requests directed to that container, matching each container’s throttle to its own observed capacity and keeping the request rate to each container near the highest rate that container can sustain while avoiding the overload that the fixed per-container limits either under- or over-shoot.
Regarding claims 2, 9, and 16, Swift as modified by Zelek teaches the computer-implemented method of claim 1, and Swift further teaches 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.
Swift teaches that the plurality of clients in aggregate can send more requests than the storage service can process, in that a single account can send thousands of requests per second to distributed containers, exceeding what the storage service can handle and necessitating an account-wide write ratelimit (pg. 2, lines 6–9).
Regarding claims 3, 10, and 17, Swift as modified by Zelek teaches the computer-implemented method of claim 1, and Swift further teaches 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.
Swift teaches that the storage service does not, of itself, enforce a per-client request-rate limit or reserve capacity, in that rate limiting is optional and, absent configured account or container limits, the storage service performs no rate limiting (pg. 1, line 10).
Claims 4–6, 11–13, and 18–20 are rejected under 35 U.S.C. § 103 as being unpatentable over Swift and Zelek, as applied to claims 1, 8, and 15 above, in further view of Vansteenkiste et al. (US 2021/0191650 A1; “Vansteenkiste”).
Regarding claims 4, 11, and 18, Swift as modified by Zelek teaches the computer-implemented method of claim 1, but does not teach wherein requests to the first storage of the storage service comprise multiple different types of operations that are prioritized based on at least a type of the corresponding operation. Nonetheless, Vansteenkiste teaches a request throttling manager having a request class sorter that sorts requests by a class identifier indicating priority classes, certain classes of requests being handled out of order, wherein the data operation of a request is a GET (read) or PUT (write) operation and the class is determined using the type of request (for example, read, write, or delete), such that requests comprising multiple different types of operations are prioritized based on the type of the corresponding operation ([0040]–[0041]).
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 method of Swift as modified by Zelek so that requests to the first storage comprising multiple different types of operations are prioritized based on at least a type of the corresponding operation, as taught by Vansteenkiste, because prioritizing requests by operation type allows more critical operation types to be handled ahead of less critical ones when capacity is constrained, improving the responsiveness of the storage service for the operations that matter most.
Regarding claims 5, 12, and 19, Swift as modified by Zelek teaches the computer-implemented method of claim 1, but does not teach 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 to each container or bucket accessed by the one or more nodes. Nonetheless, Vansteenkiste teaches a plurality of storage nodes for which the system generates an estimated preferred throughput per storage node by dividing the node’s throughput by its utilization rate, thereby determining an available capacity for processing requests to each node accessed by the system ([0011]).
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 method of Swift as modified by Zelek so that the computing cluster comprises a plurality of nodes and one or more nodes determine an available capacity for the storage service to process requests to each container or bucket, as taught by Vansteenkiste, because determining the available capacity of each storage allows the throttling to be matched to the capacity actually available at that storage, avoiding both overload and underutilization.
Regarding claims 6, 13, and 20, Swift as modified by Zelek and Vansteenkiste teaches the computer-implemented method of claim 5, further comprising:, but does not teach monitoring additional requests submitted to a second storage service to determine success or failure rates of the additional monitored requests, wherein the additional requests are directed to a third storage; and adaptively throttling requests to the third storage of the second storage service, wherein the requests to the third storage of the second storage service are throttled based on success or failure rates of the additional monitored requests submitted to the second storage service. This limitation recites a mere duplication of the monitoring-and-throttling scheme already taught for claim 1 above, applied to a second storage service and a third storage.
Swift as modified by Zelek already performs, for the storage service, the monitoring of requests to determine success or failure rates and the adaptive throttling of requests to each storage based on those rates, as set forth for claim 1 above. The mere duplication of essential working parts of a device involves only routine skill in the art; providing a second storage service with a third storage and applying the same monitoring-and-throttling scheme to it is a duplication of the storage service and storage already taught, with no new or unexpected result. See MPEP § 2144.04(VI)(B).
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 method of Swift as modified by Zelek and Vansteenkiste so that additional requests submitted to a second storage service directed to a third storage are monitored and adaptively throttled based on the success or failure rates of the additional monitored requests, because duplicating the monitoring-and-throttling scheme onto a second storage service extends the same overload protection to that additional storage service, a predictable result of applying a known technique to a known additional resource.
Claims 7 and 14 are rejected under 35 U.S.C. § 103 as being unpatentable over Swift and Zelek, as applied to claims 1 and 8 above, in further view of the non-patent literature entitled “Configure Object Storage cross-region replication for Disaster Recovery” (“Oracle DR”).
Regarding claims 7 and 14, Swift as modified by Zelek teaches the computer-implemented method of claim 1, but does not teach wherein the computing cluster uses a first container or bucket on the storage service for replication and disaster recovery operations and a second container or bucket on the storage service is used by a customer to load customer data. Nonetheless, Oracle DR teaches configuring cross-region object replication for disaster recovery in which a destination bucket holds a read-only replicated copy of objects for recovery from a regional outage, while a source bucket holds the customer data that the customer loads and from which objects are replicated, such that a first bucket is used for replication and disaster recovery operations and a second bucket is used by a customer to load customer data (pg. 7, lines 3–7).
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 method of Swift as modified by Zelek so that the computing cluster uses a first container or bucket for replication and disaster recovery operations and a second container or bucket for a customer to load customer data, as taught by Oracle DR, because maintaining a replicated disaster-recovery copy in a separate bucket protects the customer’s data against a regional outage without disrupting the customer’s use of the source bucket.
Alternatively, claims 6, 13, and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Swift, Zelek, and Vansteenkiste, as applied to claims 5, 12, and 19 above, in further view of the non-patent literature entitled “Tiering HDFS over external storage systems” (“HDFS Tiering”).
Regarding claims 6, 13, and 20, Swift as modified by Zelek and Vansteenkiste teaches the computer-implemented method of claim 5, further comprising:, but does not teach monitoring additional requests submitted to a second storage service to determine success or failure rates of the additional monitored requests, wherein the additional requests are directed to a third storage;. Nonetheless, the combination of Swift, Zelek, and HDFS Tiering teaches monitoring additional requests submitted to a second storage service to determine the success or failure rates of those requests, the additional requests being directed to a third storage: HDFS Tiering teaches a computing cluster whose nodes use a client for an external store, distinct from the storage service the cluster otherwise accesses, to read blocks from that external store, thereby directing a subset of the cluster’s requests to a third storage of that second storage service (HDFS Tiering, pg. 2, lines 28–29). Swift directs requests to a given storage of the storage service (Swift, pg. 1, lines 24–26), and Zelek monitors the requests directed to a given storage to determine the success or failure rates of that storage’s requests (Zelek, col. 4, lines 38–55), which monitoring, applied to that subset of requests directed to the third storage, determines the success or failure rates of the additional monitored requests submitted to the second storage service.
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 method of Swift as modified by Zelek and Vansteenkiste so that additional requests directed to a third storage of a second storage service accessed by the computing cluster are monitored to determine their success or failure rates, as taught by HDFS Tiering, because a cluster of the kind taught by Swift in ordinary use directs requests to more than one storage service, and monitoring those additional requests detects when the second storage service is failing requests due to overload before further failures occur.
The combination of Swift, Zelek, and HDFS Tiering further teaches adaptively throttling requests to the third storage of the second storage service, wherein the requests to the third storage of the second storage service are throttled based on success or failure rates of the additional monitored requests submitted to the second storage service.
The combination of Swift, Zelek, and HDFS Tiering teaches adaptively throttling the requests to the third storage of the second storage service based on the success or failure rates of the additional monitored requests: HDFS Tiering supplies the third storage of the second storage service accessed by the cluster (HDFS Tiering, pg. 2, lines 28–29), and Zelek adjusts, for each target and based on the success rate maintained for that target, a metric related to a sent request and a subsequently sent request to that target, increasing the time between requests or decreasing the number of subsequently sent requests when that target’s success rate indicates overload (Zelek, col. 7, lines 11–25), which adjustment, applied to the third storage, throttles the requests to the third storage of the second storage service based on the success or failure rates of the additional monitored requests submitted to that second storage service.
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 method of Swift as modified by Zelek, Vansteenkiste, and HDFS Tiering so that the requests to the third storage of the second storage service are adaptively throttled based on the success or failure rates of the additional monitored requests directed to that third storage, because governing the third storage by the success rate of its own requests matches its throttle to its own observed capacity, keeping the request rate to the second storage service near the highest rate it can sustain while avoiding overload.
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
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
Prosecution Insights