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 .
Response to Application
This office action is in response to the Application filed on 12/26/2024.
Claims 1-20 are presented for examination.
Drawings
The drawings submitted on 12/26/2024 are accepted.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Singha et al. (US 11,403,212; hereinafter referred as Singha), in view of Gupta et al. (US 2023/0164074; hereinafter Gupta), further in view of Donnelly (NPL: “How to stop getting rate limited by API” published on 03/15/2023; disclosed in IDS filed on 03/13/2025).
Regarding independent claims 1 and 14, taking claim 14 as exemplary analysis, Singha teaches A system for configurable caching, deduplication, and Fig. 1, system), the system comprising: a deduplication cache (Fig. 1, a deduplicated (DD) assisted cache 112 ); a main cache different from the deduplication cache (Fig. 1, a content based read cache (CBRC) 110); at least one processor (Fig. 1 & col. 4, ll. 29-33, Hardware platform 106 of host 102 includes physical resources of a computing device, such as a memory 108 and local storage 114. Hardware platform 106 may include other physical resources of a computing devices, not shown in FIG. 1, such as one or multiple processor(s)); and at least one memory comprising a plurality of instructions stored thereon that, in response to execution by the at least one processor (claim 10, A non-transitory computer readable medium comprising instructions that, when executed by one or more processors of a computing system, cause the computing system to perform a method for caching data in a virtualized computing system), causes the system to:
receive a data request initiated by a user interface element of a user interface; determine whether the deduplication cache includes a deduplication entry associated with the data request; determine whether the main cache includes a cache entry associated with the data request in response to a determination that the deduplication cache does not include the deduplication entry (col. 7, ll. 45-64, As an illustrative example of a read request in the host computing system 100, a second I/O requesting to read second data, D2, for a second LBA, LBA2, may have higher chances of being read from the cache when D2 is highly duplicated data and a DD caching policy is implemented to assist an LRU policy of the CBRC 110. In such a case, a hash (H2) of D2 may be retrieved from the in-memory digest file 138 for LBA2. The retrieved hash H2 for D2 may be used to find a memory location of D2 in CBRC 110 using CBRC lookup table 126. If H2 is found in CBRC lookup table 126, D2 may be retrieved from the CBRC 110. If H2 is not found in CBRC lookup table 126, H2 may be used to find a memory location of D2 in DD cache 112 using DD cache lookup table 136. If H2 is found in DD cache lookup table 136, D2 may be retrieved from the DD cache 112. When H2 is located in DD cache 112, metadata associated with D2 may be moved to CBRC 110, and removed from DD cache 112, accordingly); and
make the data request to a backend system after a determination that one of (i) the main cache does not include the cache entry associated with the data request (col. 7, ll. 65-64, If H2 is not found in CBRC lookup table 126 or DD cache lookup table 136, D2 may be retrieved from the virtual disk file 140 in storage 116).
Singha does not expressly teach the cache entry associated with the data request has expired nor rate limiting handling.
In an analogous art of cache management, Gupta teaches the cache entry associated with the data request has expired ([0030], For future requests from the user’s application for information, the application again queries the application cache. If the information still resides in the application cache, the information may be provided to the user. If the information is not in the application cache (e.g., never previously in the application cache or previously in the application cache but deleted as its associated TTL had expired and the information deleted), the application queries the data store for the information).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention was made, with the teachings of Singha and Gupta before them, to incorporate Gupta’s retrieving requested data from persistent storage when associated TTL of cached data had expired for the motivation that With longer TTLs, there is a greater chance that data is stale. Serving stale data to consumers creates consumer dissatisfaction with the service providers’ ability to provide timely data to the consumers (Gupta, [0003]).
Thus, the combination of Singha and Gupta teaches make the data request to a backend system after a determination that one of (i) the main cache does not include the cache entry associated with the data request or (ii) the cache entry associated with the data request has expired.
Singha and Gupta do not teach rate limiting handling.
In an analogous art of memory management, Donnelly teaches rate limiting handling (pp. 5-6, Defining a rate limit manager …The most basic function of a rate limit manager is the ability to programmatically define all the different rate limits you want to account for. It’s not uncommon for platforms to have more than one rate limit or even variations of different types. You’ll want to be able to define one or more rate limits per platform you’re integrating with. We’ve also found that while the majority of rate limit tracking occurs at a platform-wide level, some APIs adjust rate limits for specific end-users. Therefore, our rate limit tracker stores two types of information: platform-specific details and end-user-specific details.
The definitions of platform-specific rate limit tracking we recommend using are:
Rate Limit Type: The type of rate limit we’re defining
Rate Limit Default Threshold: The default threshold of where to start slowing down requests or stopping them completely.
Rate Limit Max Count: This is the number of “incidents” where rate-limiting starts should start kicking in. We say “incident” to accommodate the different rate limit types. For example, a request frequency rate limit of 10/s will have a max count value of 10.
Rate Limit Time Period: The time range that the limit is defined over. Typically will be seconds, minutes, or days.
Rate Limit Time Value: The amount of your time period that the expiration of a rate limit is set to. For example, a model count rate limit of 300 entities every 2 hours will have a time period of HOURS and a time value of 2. Using both period and value will let you configure pretty much any time range that will be defined for a rate limit
Default Backoff Factor + Retry Count: Related to how to manage to lower your rate limit. We’ll discuss this in more detail in our “What To Do If a Rate Limit Threshold Has Been Reached” section).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention was made, with the teachings of Singha, Gupta and Donnelly before them, to incorporate Donnelly’s rate limiting technique with Singha and Gupta’s data request to retrieve requested data from data storage for the motivation to control the number of operations a user or system can perform within a specific time, preventing server overload, abuse, and ensuring fair resource use.
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 §§ 706.02(l)(1) - 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 rejected on the ground of nonstatutory double patenting as being anticipated by claims 1-20 of U.S. Patent No. 12,210,453 (hereinafter PAT).
Although the claims at issue are not identical, they are not patentably distinct from each other because the instant claims are anticipated as shown below.
Current application
PAT
1,14
receiving a data request initiated by a user interface element of a user interface;
determining whether a deduplication cache includes a deduplication entry associated with the data request;
determining whether a main cache, different from the deduplication cache, includes a cache entry associated with the data request in response to determining that the deduplication cache does not include the deduplication entry; and
making the data request to a backend system after (i) determining that the main cache does not include the cache entry associated with the data request or (ii) determining that the cache entry associated with the data request has expired.
1
receiving a data request initiated by a user interface element of a user interface;
determining whether a deduplication cache includes a deduplication entry associated with the data request;
determining whether a main cache, different from the deduplication cache, includes a cache entry associated with the data request in response to determining that the deduplication cache does not include the deduplication entry;
determining whether the data request is associated with a rate-limited group of application programming interface endpoints in response to one of (i) determining that the main cache does not include the cache entry associated with the data request or (ii) determining that the cache entry associated with the data request has expired; and …
2,15
making the data request to the backend system further comprises making the data request in response to further determining that the data request is associated with a rate-limited group of application programming interface endpoints and that a predefined server retry period associated with the rate-limited group has elapsed
1
making the data request to a backend system after a predefined server retry period associated with the rate-limited group has elapsed in response to determining that the data request is associated with the rate-limited group.
3
determining whether the deduplication cache includes a deduplication entry associated with the data request comprises determining whether the deduplication cache includes a promise associated with a previous data request for the data object that was sent to the backend system within a predefined period of time
2
11
the deduplication entry indicates that a previous data request identical to the data request initiated by the user interface element of the user interface was made within a threshold period of time.
the deduplication cache is configured to store one or more promises, wherein each of the one or more promises is associated with a previous respective data request.
4,16
determining whether the cache entry associated with the data request has expired based on a creation time of the cache entry and a predefined maximum cache age associated with the data request, wherein the predefined maximum cache age overrides an expiration time associated with the cache entry
4
determining whether the cache entry associated with the data request has expired based on a creation time of the cache entry and the predefined maximum cache age in response to determining that the data request is associated with the predefined maximum cache age.
5,17
determining whether the cache entry associated with the data request has expired based on an expiration time of the cache entry defined by the cache entry in response to determining that the data request is not associated with a predefined maximum cache age
5
determining whether the cache entry associated with the data request has expired based on an expiration time of the cache entry defined by the cache entry in response to determining that the data request is not associated with the predefined maximum cache age
6
making the data request to the backend system immediately in response to determining that the data request is not associated with a rate-limited group
6
making the data request to the backend system immediately in response to determining that the data request is not associated with any rate-limited group
7,18,19
receiving an error associated with the data request in response to a failure to fulfill the data request;
determining whether the error associated with the data request is a retriable error;
determining whether a predefined retry limit has been reached in response to determining that the error associated with the data request is the retriable error; and
retrying the data request in response to determining that the predefined retry limit has not been reached
7
receiving an error associated with the data request in response to a failure to fulfill the data request;
determining whether the error associated with the data request is a retriable error;
determining whether a predefined retry limit has been reached in response to determining that the error associated with the data request is the retriable error; and
retrying the data request in response to determining that the predefined retry limit has not been reached.
8
retrying the data request comprises retrying the data request after the predefined server retry period in response to determining that the retriable error is a 429 error
8
retrying the data request comprises retrying the data request after the predefined server retry period in response to determining that the retriable error is a 429 error
9
the predefined retry limit is a maximum number of retry attempts that can be made
9
the predefined retry limit is a maximum number of retry attempts that can be made
10
determining whether the data request is associated with the rate-limited group of application programming interface endpoints, including determining whether an application programming interface endpoint to which the data request is directed is included in the rate-limited group of application programming interface endpoints.
10
determining whether the data request is associated with the rate-limited group of application programming interface endpoints comprises determining whether an application programming interface endpoint to which the data request is directed is included in the rate-limited group of application programming interface endpoints.
11
the deduplication cache is configured to store one or more promises, wherein each of the one or more promises is associated with a previous respective data request
11
the deduplication cache is configured to store one or more promises, wherein each of the one or more promises is associated with a previous respective data request
12
determining whether the cache entry associated with the data request has expired by determining whether a time period associated with the cache entry in the main cache exceeds a time to live associated with the data request
12
the deduplication cache is configured to store data returned to previous data requests with a configurable timeout.
13,20
the main cache is configured to store data returned in response to previous data requests.
13
the main cache is configured to store data returned in response to previous data requests.
Allowable Subject Matter
Claims 2-13 and 15-20 would be allowable if overcome the double patenting rejection discussed above and if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRACY C CHAN whose telephone number is (571)272-9992. The examiner can normally be reached on Monday - Friday 10 AM to 6 PM EST.
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, TIM VO can be reached on (571)272-3642. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/TRACY C CHAN/ Primary Examiner, Art Unit 2138