DETAILED ACTION
In a communication received on 19 February 2026, applicants amended claims 1 and 10.
Claims 1-19 are pending.
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 Arguments
Applicant’s arguments with respect to claim(s) 1 and 10 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
With respect to claim 1, the applicants allege, "The 'central application cache', as in the present claims, is the opposite of a 'distributed cache', which is what makes it 'central.' The purpose of the 'central application cache' in the present claims is to server as a central cache" (page 9) with respect to the claimed limitation(s), "determining that the first request is not available in a central application cache accessible by the application ... storing the cache record in a container of the central application cache, wherein the container includes a copy of at least a portion of the application". The examiner respectfully traverses. The arguments/remarks pertain to whether the cited prior art does not disclose a central application cache. The examiner concludes that the cited prior art clearly discloses or suggests a global cache where every microservice can request access to shared cache objects
Ascertaining the differences between the prior art and the claims at issue requires interpreting the claim language, and considering both the invention and the prior art references as a whole (See 2141.02 "Differences Between Prior art and Claimed Invention)
As best understood by the examiner, the central application cache broadly covers a cache accessible by an application through a shared cache framework. The claim does not require a single non-distributed monolithic cache. The applicant is invited to point where in the specification this is disclosed. Accordingly, Gupta, ¶0209, discloses each tenant has a unique corresponding cache in the global cache configured to hold configuration and run-time data. Furthermore, Gupta, ¶0253, that caching framework is multi-tenant with namespaces that map to a location of the object within the caching framework corresponding to the tenant's data. Gupta, ¶0194-0195, every microservice can request access to shared cache objects. Under the BRI, Gupta distributed cache is central in that applications can access the shared portions and does not necessarily mean that the data must be stored all in a single physical location.
In conclusion, the applicants argue(s) that the cited prior art does not disclose a central application cache. The examiner traverses because the cited prior art clearly discloses or suggests a global cache where every microservice can request access to shared cache objects.
The applicants allege, "There is no indication in Gupta that the second instance of an application could receive data that is stored the first cache by the first instance of the application. Separate instances of the same application have separate caches in Gupta" (page 10) with respect to the claimed limitation(s), "matching the second request with the first request based on the first metadata and the second metadata, and the cache record in the container of the central application cache". The examiner respectfully traverses. The arguments/remarks pertain to whether the cited prior art does not disclose or suggest meta-based matching by another application instance. The examiner concludes that the cited prior art clearly discloses or suggests matching the same metadata-derived cache record to serve the cached response
Ascertaining the differences between the prior art and the claims at issue requires interpreting the claim language, and considering both the invention and the prior art references as a whole (See 2141.02 "Differences Between Prior art and Claimed Invention)
The broadest reasonable interpretation pertains to matching based on metadata the later requests to a previous request metadata. The separate computing environment of the second application instance is merely an intended use of the metadata matching cache-hit logic and does not limit the claim to explicitly recite a separate computing environment. Accordingly, Gupta, ¶0253 discloses no two tenants have their data residing at a same namespace in the cache. The record is matched based on the metadata provided with cache-hit logic returning data from near/remote cache ¶0219-0220, ¶0234, ¶0240. Gupta uses the metadata to match the cache records because it is agnostic to where the request is sourced from, therefore this suggests to one of ordinary skill in the art that a separate cloud environment is not excluded by Gupta. Under the BRI, the later request resolving to the same metadata cache record reasonably matches the cache record regardless of whether it is from a tenant's separate computing environment instance.
In conclusion, the applicants argue(s) that the cited prior art does not disclose or suggest meta-based matching by another application instance. The examiner traverses because the cited prior art clearly discloses or suggests matching the same metadata-derived cache record to serve the cached response.
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) 1-3, 5-8, 10-12 and 14-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta (US 2020/0244638 A1) in view of Topiwala et al. (US 2017/0277616 A1), and further in view of Suarez et al. (US 2017/0177860 A1).
With respect to claim 1, Gupta discloses: a method comprising:
receiving a first request at a first instance of an application hosted on a first cloud environment (i.e., receiving HTTP/API requests at IDCS APIs and forwards them to an IDCS microservice in Gupta, ¶0020, ¶0078, ¶0080);
obtaining a first response to the first request from a datastore (i.e., obtain response data by reaching database/LDAP after a cache miss in Gupta, ¶0219, ¶0258);
determining that the first request is not available in a central application cache accessible by the application (i.e., global/remote cache is accessible by the microservice and reports a cache miss in Gupta, ¶0209, ¶0219, ¶0220),
wherein the first metadata includes a first request type, a first requestor identity, a first location, and a first host cloud environment (i.e., API/service, user/client, tenant/location, and host/resource metadata in Gupta, ¶0075, ¶0076, ¶0150, ¶0151),
wherein the second metadata includes a second request type, a second requestor identity, a second location, and a second host cloud environment (i.e., the API/service, user/client, tenant/location, and host/resource metadata in Gupta, ¶0075, ¶0076, ¶0150, ¶0151);
matching the second request with the first request based on the first metadata and the second metadata, and the cache record in the container of the central application cache (i.e., compositeKeys search a unique cached record in Gupta, ¶0240, ¶0220);
determining that the second request is a duplicate of the first request based on the first metadata and the second metadata (i.e., mapping request metadata to a unique cache record, so a second request with the same key is reasonably a duplicate of the first request in Gupta, ¶0240, ¶0259).
Gupta discloses caches a returned resource after a miss and uses compositeKeys for a unique record (¶0217, ¶0240). Gupta do(es) not explicitly disclose the following. Topiwala, in order to improve durability of the record by storing as a call tree unit for later processing (¶0024, ¶0072), discloses: ; responsive to determining that the first request is not available in the central application cache, generating a cache record comprising the first request, the first response, and a first metadata that identify attributes of the first request and uniquely identify the first request (i.e., storing the request, response traffic, and propagated identifier metadata in one record in Topiwala, ¶0023, ¶0026, ¶0070).
Based on Gupta in view of Topiwala, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Topiwala to improve upon those of Gupta in order to improve durability of the record by storing as a call tree unit for later processing.
Gupta discloses central/shared cache organization and global cache and tenant distributed caches with corresponding map/namespace (¶0209, ¶0253). Gupta and Topiwala do(es) not explicitly disclose the following. Suarez, in order to improve efficiency of storage resources by storing container images as layers (¶0025), discloses:
storing the cache record in a container of the central application cache (i.e., stores manifests, layers, files/directories, and metadata as a stored container image in Suarez, ¶0021, ¶0029),
wherein the container includes a copy of at least a portion of the application (i.e., container image includes files/structure of one or more software applications and layers in Suarez, ¶0026, ¶0027, ¶0031);
receiving a second request by a second instance of the application hosted on a second cloud environment, and a second metadata that identify attributes of the second request and is sufficient to uniquely identify the second request (i.e., first-region/second-region deployment supplies the second cloud environment for the second application instance receiving the second request in Suarez, ¶0092, ¶0093);
responsive to the second request, providing the first response from the cache record to the second instance of the application hosted on the second cloud environment. (i.e., multi-region deployment supplies the second cloud environment so the cached first response can be provided to the second-region application instance in Suarez, ¶0092, ¶0093).
Based on Gupta in view of Topiwala, and further in view of Suarez, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Suarez to improve upon those of Gupta in order to improve efficiency of storage resources by storing container images as layers.
With respect to claim 2, Gupta discloses: the method of claim 1, further comprising: prior to obtaining the first response, determining that the first response is not available in a native cache of the first cloud environment (i.e., checking the near caches for the requested data, the near cache fronts a distributed or remote cache that is more local to the client in Gupta, ¶0214, ¶0219)
With respect to claim 3, Gupta discloses: the method of claim 2, wherein generating the cache record is further performed in response to determining that the first response is not available in the native cache (i.e., if a resource is being introduced to the system first time, a resource definition file is stored along with the resource in Gupta, ¶0237)
With respect to claim 5, Gupta discloses: the method of claim 1, further comprising: receiving a third request by the instance of the application hosted on the first cloud environment (i.e., a request from another tenant to interact with another tenant's namespace in Gupta, ¶0136);
determining that the third request is the same as a prior request for which a response is available in the central application cache (i.e., if the resource is a global resource, the cache can deliver this resource to any tenants in Gupta, ¶0239); and
providing the response available in the central application cache in response to the third request (i.e., receiving requested global resources if the resource is cached and at least from the global cache namespace in Gupta, ¶0237, ¶0239)
With respect to claim 6, Gupta discloses: the method of claim 5, wherein the prior request is received by an instance of the application hosted on a cloud environment different from the first cloud environment (i.e., requests can be received by a client of a different tenant in Gupta, ¶0136).
With respect to claim 7, Gupta discloses: the method of claim 1, further comprising: linking the container to the instance of the application hosted on the first cloud environment (i.e., implementing by a global cache at least a cache per tenant configured for short-lived and run-time data in Gupta, ¶0209); and
linking the container to the instance of the application hosted on the second cloud environment (i.e., delegation of authority via a token for a client of another tenant to access the namespace of another tenant in Gupta, ¶0136)
With respect to claim 8, Gupta discloses: the method of claim 1, further comprising: receiving a third request at the instance of the application hosted on the first cloud environment (i.e., a request from another tenant to interact with another tenant's namespace in Gupta, ¶0136);
determining that a response to the third request is available in a native cache of the first cloud environment (i.e., check a near cache for the requested data in Gupta, ¶0219); and
providing the response to the third request from the native cache in response to the third request (i.e., providing cached data from a near cache if it is determined available in the near cache in Gupta, ¶0219).
With respect to claim 10, the limitation(s) of claim 10 are similar to those of claim(s) 1. Therefore, claim 10 is rejected with the same reasoning as claim(s) 1.
Gupta further discloses: a cloud computing system comprising: a computer processor executing a cloud-based instance of an application in a first cloud environment (i.e., cloud computing infrastructure providing several cloud applications provided by different cloud environments in Gupta, ¶0039),
a computer processor executing a cloud-based instance of the application in a second cloud environment different from the first cloud environment (i.e., computing devices providing seamless user experience across various applications and different channels with different infrastructure such as mobile devices and desktop computer users in Gupta, ¶0039).
With respect to claim 11, the limitation(s) of claim 11 are similar to those of claim(s) 2. Therefore, claim 11 is rejected with the same reasoning as claim(s) 2.
With respect to claim 12, the limitation(s) of claim 12 are similar to those of claim(s) 3. Therefore, claim 12 is rejected with the same reasoning as claim(s) 3.
With respect to claim 14, the limitation(s) of claim 14 are similar to those of claim(s) 5. Therefore, claim 14 is rejected with the same reasoning as claim(s) 5.
With respect to claim 15, the limitation(s) of claim 15 are similar to those of claim(s) 6. Therefore, claim 15 is rejected with the same reasoning as claim(s) 6.
With respect to claim 16, the limitation(s) of claim 16 are similar to those of claim(s) 7. Therefore, claim 16 is rejected with the same reasoning as claim(s) 7.
With respect to claim 17, the limitation(s) of claim 17 are similar to those of claim(s) 8. Therefore, claim 17 is rejected with the same reasoning as claim(s) 8.
Claim(s) 4 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta (US 2020/0244638 A1) in view of Topiwala et al. (US 2017/0277616 A1) and Suarez et al. (US 2017/0177860 A1), and further in view of Gaonkar et al. (US 2020/0089607 A1).
With respect to claim 4, Gupta discloses introducing a resource into the system, along with data indicating identifiers, resource type definitions (¶0237). Gupta, Topiwala, and Suarez do(es) not explicitly disclose the following. Gaonkar, in order to improving storage capacity and lowering costs (¶0002), discloses: the method of claim 1, wherein the central application cache includes cache records generated in response to prior requests, and wherein the application cache is a standardized data storage format that is not a native cache of the first cloud environment or the second cloud environment (i.e., cache is formatted in as serialized format for the cloud storage layer in Gaonkar, ¶0033).
Based on Gupta in view of Topiwala and Suarez, and further in view of Gaonkar, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Gaonkar to improve upon those of Gupta in order to improving storage capacity and lowering costs.
With respect to claim 13, the limitation(s) of claim 13 are similar to those of claim(s) 4. Therefore, claim 13 is rejected with the same reasoning as claim(s) 4.
Claim(s) 9, 18 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta (US 2020/0244638 A1) in view of Topiwala et al. (US 2017/0277616 A1) and Suarez et al. (US 2017/0177860 A1), and further in view of Miyajima et al. (US 2015/0067270 A1)
With respect to claim 9, Gupta discloses: the method of claim 8, further comprising: storing the second cache result in a container of the central application cache (i.e., each tenant has a unique corresponding cache in the global cache configured to hold configuration and run-time data in Gupta, ¶0209).
Gupta discloses a request from another tenant to interact with another tenant's namespace; providing cached data from a near cache if it is determined available in the near cache (¶0136, ¶0219). Gupta, Topiwala, and Suarez do(es) not explicitly disclose the following. Miyajima, in order to improve the effectiveness of caching despite differences in variable information of requests (¶0021), discloses: generating a second cache record comprising the third request, the response to the third request, and metadata that is sufficient to uniquely identify the third request (i.e., multiple inquiries and requests with metadata that distinguishes them, ¶0023; and determining whether a response is already cached, cache and store a response corresponding to the requests metadata; the cache stores in association the request parameters that can be searched to receive the response, the parameters are metadata that include an account number, transaction id, or time of the request in Miyajima, ¶0021, ¶0025, ¶0028).
Based on Gupta in view of Topiwala and Suarez, and further in view of Miyajima, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Miyajima to improve upon those of Gupta in order to improve the effectiveness of caching despite differences in variable information of requests.
With respect to claim 18, the limitation(s) of claim 18 are similar to those of claim(s) 9. Therefore, claim 18 is rejected with the same reasoning as claim(s) 9.
With respect to claim 19, Gupta discloses a global cache implementing caching of short-lived and run-time data for tenants of the computing ecosystem (¶0209). Gupta, Topiwala, and Suarez do(es) not explicitly disclose matching of responses based on their respective metadata to provide cached data. Miyajima, in order to improve the effectiveness of caching despite differences in variable information of requests (¶0021), discloses: the method of claim 1,
wherein the attributes of the first request do not include extraneous information irrelevant to the first request (i.e., metadata may be excluded from cache searching or caching decisions to satisfy subsequent requests with different variable information or avoid problematic metadata in Miyajima, ¶0039), and
the attributes of the second request do not include extraneous information irrelevant to the second request (i.e., selectively including certain metadata into cache searching decisions in Miyajima, ¶0039).
Based on Gupta in view of Topiwala and Suarez, and further in view of Miyajima, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Miyajima to improve upon those of Gupta in order to improve the effectiveness of caching despite differences in variable information of requests.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHERMAN L LIN whose telephone number is (571)270-7446. The examiner can normally be reached Monday through Friday 9:00 AM - 5:00 PM (Eastern).
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, Joon Hwang can be reached on 571-272-4036. 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.
Sherman Lin
5/30/2026
/S. L./Examiner, Art Unit 2447
/JOON H HWANG/Supervisory Patent Examiner, Art Unit 2447
Prosecution Insights