DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 05/12/2026.
Claims 1, 2, 13, 14, 19, and 20 have been amended.
Claims 3, 4, and 15 have been cancelled.
Claims 1, 2, 5-14, and 16-20 are currently pending and have been examined.
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 and amendments filed 05/12/2026 have resolved the prior identified 112m issues and the rejections under 35 USC § 112 have accordingly been withdrawn.
Applicant’s arguments filed 05/12/2026 with respect to the rejections under 35 USC § 102/103 have been considered but are moot in view of the new grounds of rejection.
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, 2, 5-7, 11, 13, 14, 16, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Nawrocke et al. (US 2020/0356559 A1) in view of Azar et al. (US 2010/0332513 A1).
Claims 1, 11, 13, and 19:
Nawrocke discloses the limitations as shown in the following rejections:
A hybrid-cloud infrastructure environment facilitating resilient data access through access routing, the hybrid-cloud infrastructure environment comprising: at least one public-cloud server (e.g. 102a); at least one private on-premise server (e.g. 102c) (0031-0035, 0101; FIG. 1); “database environment may include databases implemented on multiple computing platforms 102a-102c, such as a first cloud computing platform 102a…a datalake 102b implemented on a second cloud computing platform, on-premise computing equipment, or other computing platform; and an on-premise computing platform 102c.” (¶0031)
a computer system comprising: at least one processor; a communication interface communicatively coupled to the at least one processor; and a memory device storing executable code that, when executed, causes the at least one processor to: receive, via a client device (user computing device), an application programming interface (API) call to access (query, e.g. fetch) a portion of data (¶0036-0039, 0072-0075; FIG. 1).
dynamically select a source from which to source the portion of the data, wherein the source is selected from the group consisting of (i) the at least one public-cloud server, (ii) the at least one private on-premise server, and (iii) a cloud operational data store (local computing platform “P” cache), wherein the dynamically selecting comprises analyzing one or more predefined factors (e.g. metrics, constraints, policies, filters) (¶0090-0094, 0183-0186, 0200-0202; FIG. 4 and 18), “The sources S1-S3…may be embodied as any of the computing platforms 102a-102c…method 400 may include identifying 406 possible alternative sources for performing each operation. For example, FIG. 5A shows one set of alternatives with…data accesses being performed on the sources S1-S3 storing the data being accessed (¶0090-0091)…method 400 may include determining 408 metrics for each alternative according to the query performance model (¶0093)”
transmit a request to the source to access the portion of the data; retrieve the portion of the data (query result) from the source; and expose the portion of the data for access via the client device (¶0073-0075, 0096, 0123-0124), “The operation may be executed 1204 with respect to the source. In particular, the engine 104 may issue a request to the source that the subject table and the database 1002 to perform the operation. The source returns a result of the operation to the engine 104, which returns the result to the interface 108a-108c that issued the query that included the operation through the unified access layer” (¶0124).
[Claim 11, 13, 19] redundantly store the data to (iii) the cloud operational data store (local computing platform “P” cache) from (i) the at least one public-cloud server and (ii) the at least one private on-premise server (¶0093, 0200-0203, 0063).
Regarding the limitation reciting wherein at least one of the one or more predefined factors comprise data type of the portion of the data such that the dynamically selecting comprises analyzing the data type of the portion of the data, wherein the data type identifies whether the portion of the data is dynamic data or static data, Nawrocke suggests the subject matter in at least ¶0060 disclosing monitored metrics include: “Temporal information (how often data is updated, how often should the system update it (e.g., in a cache))” and ¶0138-0141 disclosing that determining whether to use a cached source for a particular table can be based on an update frequency of the data in the table, but Nawrocke does not clearly anticipate that the selecting is based on data type identifies whether the portion of the data is dynamic data or static data.
Azar, however, discloses analogous methods of maintaining cached data sources wherein “the source items may be variably dynamic, referring to the volatility of the presence and the content of items: some items may be static, other items may be updated infrequently, and other items may change frequently; and where some items are updated at a consistent frequency, while updates of other items are fluctuating or erratic” (¶0001). Azar analyzes the source iutems to determine a predicted update frequency (data type) for the source items and compute a refresh probability that dictates whether the item will be sourced from the cache or its origin source (¶0023-0026) including only sourcing from cache for a itme “the source item 18 may be completely static”.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Nawrocke with Azar refresh probability to obtain data items from a source with better performance (¶0029, 0001).
Claims 2, 14, and 20:
The combination of Nawrocke/Azar discloses the limitations as shown in the rejections above. Nawrocke further discloses wherein the one or more predefined factors further comprise at least one of data state and data availability (¶0040-0043, 0181-0183).
Claims 5, 6 and 16:
The combination of Nawrocke/Azar discloses the limitations as shown in the rejections above. Nawrocke further discloses wherein at least one of the one or more predefined factors comprise a data state of the portion of the data such that the dynamically determining comprises analyzing the data state of the portion of the data…wherein the data state comprises metadata comprising at least one of historical status (e.g. update frequency, query history) of the portion of the data and pendency status (e.g. cache version validity) of the portion of the data (¶0128-0134, 0182, 0188, 0201-0202).
Claim 7:
The combination of Nawrocke/Azar discloses the limitations as shown in the rejections above. Nawrocke further discloses wherein at least one of the one or more predefined factors comprise data availability due to reliability and timeliness for accessing the portion of the data (¶0043-0046,0068-0070, 0182).
Claims 8, 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Nawrocke in view of Azar in further view of Cao et al. (“PolarDB-X: An Elastic Distributed Relational Database for Cloud-Native Applications”, 2022).
Claims 8 and 18:
The combination of Nawrocke/Azar discloses the limitations as shown in the rejections above. Nawrocke further discloses (FIG. 1 and 16; ¶0036-0038, 0040-0043, 0186-0189) the hybrid multi-cloud data management system includes an API layer (unified access layer 106) facilitate the API call by communicating the API call to a respective data access router (query engine 104) by way of a respective data access engine (tuning module) and a respective data provider registry (policies 110 and metrics 116 storage). Nawrocke further discloses (¶0062) that the query engine is scalable and “may expand storage and computation resources allocated to the scalable query engine 104 in response to usage data”, but does not describe scaling the number of instances and does not specifically disclose the hybrid cloud infrastructure environment further comprises an external load balancer configured to direct the API call to at least one instance of two instances of an API layer, the two instances comprising a read only instance and a read/write instance, wherein the at least one instances is selected based on geographic proximity.
Cao, however, discloses (pg. 2860-2861, sect. II-A and Fig. 2; pg. 2862, sect. II-C and Fig. 3; pg. 2866, col. 1, para. 2) an analogous distributed database system including an external load balancer configured to direct the API call to at least one instance of two instances of a computation node (CN) with corresponding data node (DN) where the two instances comprising a read only (RO) instance and a read/write (RW) instance, wherein the at least one instances is selected based on geographic proximity. Exemplary quotation:
"The load balancer...exposes a single entry point (i.e., virtual IP) to SQL clients for each PolarDB-X instance. It is location aware, which tends to disperse client connections to nearby backends (e.g., CN servers co-located in the same datacenter)...A CN is always deployed in the same datacenter with underlying DN...DN is equivalent to the database nodes (RW and RO nodes) in PolarDB...an instance includes one primary (i.e., RW node) and multiple read replicas (i.e., RO nodes). RO replicas can be scaled horizontally to improve the capacity of processing analytical queries" (pg. 2861, sect. II-A).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Nawrocke/Azar’s query engine in accordance with the architecture of Cao’s PolarDB-X system to facilitate rapid horizontal scaling to improve the capacity of processing analytical queries and to leverage “a series of DBA- and developer-friendly features in PolarDB-X to enhance usability, e.g., anti-hotspot, automated traffic control, and index recommendation.” (see Cao pg. 2860-2861).
Claim 9:
The combination of The combination of Nawrocke/Azar/Cao discloses the limitations as shown in the rejections above. Nawrocke further discloses (FIG. 1 and 16; ¶0036-0038, 0040-0043, 0186-0189) wherein the dynamically determining is performed based on communication between the respective data access engine (tuning module) and the respective data provider registry (policies 110 and metrics 116 storage), and wherein the transmitting is performed, at least in part, via the respective data access router (query engine).
Claims 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Nawrocke in view of Azar in further view of Padbidri et al. (US 2022/0405294 A1) in further view of Gilmartin (US 2015/0332422 A1).
Claims 10 and 17:
The combination of Nawrocke/Azar discloses the limitations as shown in the rejections above. Nawrocke further discloses (¶0093-0096, 0200-0203) wherein a default source of the data is the cloud operational data store (local platform cache). Nawrocke/Azar does not elaborate on the data transfer process when transferring data from sources to the local platform cache and does not specifically disclose wherein the cloud operational data store is configured to coordinate with a data ingestion and transformation engine to extract, transform, and load the data, wherein the data ingestion and transformation engine facilitates both batch file loading of encrypted files from data providers and processing of streaming events from the data providers, wherein the data providers comprise (i) the at least one public-cloud server and (ii) the at least one private on-premise server.
Padbidri, however, discloses (¶0089-0103; FIG. 5) “a cloud native ETL module (CNETLM)” (data ingestion and transformation engine) that is configured to extract, transform, and load the data, wherein the data ingestion and transformation engine facilitates both batch file loading of(streaming/real-time data) from the data providers, wherein the data providers comprise (i) the at least one public-cloud server and (ii) the at least one private on-premise server.
“cloud native ETL module (CNETLM)…configured to fetch the desired data from the one or more data sources, e.g., real time/streaming source 502 and/or the batch source 504, based on the configuration details data to be utilized for the desired data processing scheme…sources and targets 602 can be on premises or cloud based (¶0090-0091)…may be further configured to implement a common code base for executing ETL across both the batch processing mode and the real time processing mode” (¶0103).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Nawrocke/Azar data transfer to the platform cache to employ Padbidri’s CNETLM to facilitate user-friendly configuration for transferring data from diverse sources following a uniform configuration (Padbidri ¶0051, 0102).
The combination of Nawrocke/Azar/Padbidri does not describe characteristics of the underlying data content and does not specify that it is encrypted.
Gilmartin, however, discloses an analogous “ETL process extracts data from outside sources, then transforms it to fit the needs of the overall system, then loads it into the end target (most preferably a database)” (¶0056); and further discloses (¶0060-0061, 0078-0079) the ETL process supports batch file loading of encrypted files from data providers, “a copy of the encrypted file is created and kept in a separate FTP archive location, not shown in drawings. The system will decrypt the file, 323, and start data validation…final processed data is stored in the SQL “CRXProd” database” (¶0060).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Nawrocke/Azar/Padbidri to handle encrypted files as taught by Gilmartin to increase data security and integrity (Gilmartin ¶0071-0075).
Claims 12 is rejected under 35 U.S.C. 103 as being unpatentable over Nawrocke in view of Azar in further view of Gilmartin (US 2015/0332422 A1).
Claim 12:
The combination of Nawrocke/Azar discloses the limitations as shown in the rejections above. Nawrocke further discloses (¶0093, 0200-0202, 0122, 0141, 0033) wherein the redundantly storing comprises periodically performing batch file transfers (transferred a priori) from(updates/changes)
“Caching may be performed prior to receiving a query…The cached data may also be updated…in response to detecting a change in the version of the cached data in the source from which it was retrieved. Evaluating of whether a cached table is different from the version of the table at the source from which it is retrieved may be performed…periodically, or in response to detecting writing of data to that table on the source” (¶0200-0201).
Nawrocke/Azar does not describe characteristics of the underlying data content and does not specify that it is encrypted.
Gilmartin, however, discloses an analogous “ETL process extracts data from outside sources, then transforms it to fit the needs of the overall system, then loads it into the end target (most preferably a database)” (¶0056); and further discloses (¶0060-0061, 0078-0079) the ETL process supports batch file transfers from encrypted files from data providers, “a copy of the encrypted file is created and kept in a separate FTP archive location, not shown in drawings. The system will decrypt the file, 323, and start data validation…final processed data is stored in the SQL “CRXProd” database” (¶0060).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Nawrocke/Azar to handle encrypted files as taught by Gilmartin to increase data security and integrity (Gilmartin ¶0071-0075).
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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
08/05/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights