Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/08/2026 has been entered.
Detailed Action
Applicant amended claims 1, 4-5, 7, 10-11, 13 and 16-17 and presented claims 1-18 for reconsideration on 07/08/2026.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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, 7 and 8 are rejected under 35 U.S.C. 103(a) as being unpatentable over CRUANES et al., Pub. No.: US 2023/0297589 A1 (CRUANES) in view of SHEN et al., Pub. No.: US 2023/0153302 A1 (SHEN)
Claim 1. CRUANES teaches:
A tiered database system, comprising: a memory, the memory comprising:
a data warehouse that is configured to store obtained data; (¶ 24, “a data storage system utilizes an SQL (Structured Query Language )-based relational database. However, these systems and methods are applicable to any type of database, and any type of data storage and retrieval platform, using any data storage architecture and using any language to store and retrieve data within the data storage and retrieval platform”)
a relational layer, wherein the relational layer stores a copy of a subset of the obtained data; and (¶ 24, “a data storage system utilizes an SQL (Structured Query Language )-based relational database”), ¶ 31, cache layers store a copy of subset of data: “Some nodes may have already cached the data needed to process the query and, therefore, are good candidates for processing the query”)
wherein the subset of the obtained data comprises entries stored in the data warehouse within a certain period of recency; and (recently accessed data is cached: ¶¶ 31, 72, “the most frequently accessed data is stored in the memory and the least frequently accessed data is stored in the hard disk drive… a least-recently used (LRU) algorithm is utilized to manage the storage of data in the multiple storage devices”)
a proxy layer, comprising:
a collection of relational metadata comprising a set of database metrics for a tiered database, wherein the set of database metrics is derived from the obtained data; and (¶¶ 26, 34 metadata includes information/statistics about the stored data in the system: “metadata…is associated with the entirety of data stored throughout data processing platform 100…metadata 110 includes a summary of data stored in remote data storage systems as well as data available from a local cache…metadata 110 may include information regarding how data is organized in the remote data storage systems and the local caches. Metadata 110 allows systems and services to determine whether a piece of data needs to be accessed without loading or accessing the actual data from a storage device”)
wherein the set of databases metrics comprises: a first set of database metrics corresponding to the data warehouse; and a second set of database metrics corresponding to the relational layer; (¶ 26, metadata “is associated with the entirety of data stored throughout data processing platform”)
a query planner, wherein the query planner is configured to generate instructions for query routing; and (¶ 56, “virtual warehouse resource manager 508…routes the data retrieval and data storage requests to an appropriate virtual warehouse 510-514 in virtual warehouse group 516…virtual warehouse resource manager 508 to distribute multiple requests across the virtual warehouses 510-514 based on efficiency, available resources, and the availability of cached data within the virtual warehouses 510-514”)
at least one processor, the at least one processor configured to execute the instructions to:
receive, from a sender, a database query corresponding to the obtained data; (¶ 34, “SQL optimizer 214 determines the best method to execute queries based on the data that needs to be processed. SQL optimizer 214 also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of executing the SQL query. SQL executor 216 executes the query code for queries received by resource manager 102”; ¶ 56, “virtual warehouse resource manager 508…routes the data retrieval and data storage requests to an appropriate virtual warehouse 510-514 in virtual warehouse group 516…virtual warehouse resource manager 508 to distribute multiple requests across the virtual warehouses 510-514 based on efficiency, available resources, and the availability of cached data within the virtual warehouses 510-514”)
determine a preliminary query plan to respond to the database query; (¶ 34, “SQL optimizer 214 determines the best method to execute queries based on the data that needs to be processed”, ¶ 56)
recover, from the collection of relational metadata, the set of database metrics; (¶ 26, metadata is used for running a query: “metadata…is associated with the entirety of data stored throughout data processing platform 100…metadata 110 includes a summary of data stored in remote data storage systems as well as data available from a local cache…metadata 110 may include information regarding how data is organized in the remote data storage systems and the local caches. Metadata 110 allows systems and services to determine whether a piece of data needs to be accessed without loading or accessing the actual data from a storage device”, ¶¶ 34, 56)
compute, from the set of database metrics and the preliminary query plan, a storage access cost, wherein the storage access cost comprises an estimate for time required to respond to the database query; and (¶ 26, wherein, “to improve the speed and efficiency of executing the SQL query” suggests an optimized query includes an estimated time for improved speed and efficiency of executing the query, ¶¶ 34, 56)
route the database query based on the storage access cost, (¶ 26, wherein, “to improve the speed and efficiency of executing the SQL query” suggests a query is routed to a storge, a cache or a remote storage based on the access cost)
wherein the database query is routed to the data warehouse when the storage access cost exceeds a predetermined execution time threshold; and (¶ 26, wherein, “to improve the speed and efficiency of executing the SQL query” suggests a query is routed to a storge, a cache or a remote storage based on the access cost. Note that when the storage access cost exceeds a predetermined execution time threshold is a conditional statement that is not necessarily implementable. Furthermore, access cost exceeding/not exceeding a predetermined execution time threshold depends on a design choice for a threshold. For example, a predetermined threshold can be simply an expected short time for processing a query as fast as possible, as in ¶ 31 because the goal of the system is generating a response using cached data: “It is desirable to retrieve as much data as possible from caches within execution platform 112 because the retrieval speed is typically much faster than retrieving data from storage platform”. Evidently, when data is retrieved from a remote storge, the cost of processing the query exceeds an expected short time for processing a query and when data is retrieved from a local cache the cost of processing the query does not exceed an expected short time for processing a query)
wherein the database query is routed to the relational layer when the storage access cost does not exceed the predetermined execution time threshold; and (¶ 26, wherein, “to improve the speed and efficiency of executing the SQL query” suggests a query is routed to a storge, a cache or a remote storage based on the access cost. Note that when the storage access cost does not exceed the predetermined execution time threshold is a conditional statement that is not necessarily implementable. Furthermore, access cost exceeding/not exceeding a predetermined threshold depends on a design choice for a threshold. For example, a predetermined threshold can be simply an expected short time for processing a query as fast as possible, as in ¶ 31 because the goal of the system is generating a response using cached data: “It is desirable to retrieve as much data as possible from caches within execution platform 112 because the retrieval speed is typically much faster than retrieving data from storage platform”. Evidently, when data is retrieved from a remote storge, the cost of processing the query exceeds an expected short time for processing a query and when data is retrieved from a local cache the cost of processing the query does not exceed an expected short time for processing a query)
receive a result to the database query from at least one selected from the group consisting of the data warehouse and the relational layer; and (¶ 64, “Each execution node performs an assigned task and returns a task result to the resource manager…the execution nodes return the task results to the query coordinator. The resource manager receives the multiple task results and creates a statement result at 712, and communicates the statement result to the user”)
return the result to the database query to the sender. (¶ 64, “Each execution node performs an assigned task and returns a task result to the resource manager…the execution nodes return the task results to the query coordinator. The resource manager receives the multiple task results and creates a statement result at 712, and communicates the statement result to the user”)
CRUANES did not specifically disclose but SHEN discloses wherein the storage access cost is initialized from the preliminary query plan and updated, in real-time, based on: a first cost derived from the first set of database metrics: and a second cost derived from the second set of database metrics. (Abs, “An access plan to process a query to the virtual database is optimized based on the real time system statistics and the real time data source statistics and a response is produced based on the access plan, with improved performance and reduced cost”; ¶¶ 3, 57, 67)
It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing is initialized from the preliminary query plan and updated, in real-time, based on: a first cost derived from the first set of database metrics: and a second cost derived from the second set of database metrics because doing so would provide for improving both a response time of the query and a cost of processing based on the real-time information.
Claim 7. CRUANES teaches:
A method for operating a query planner, the method comprising:
receiving, from a sender, a database query made to a tiered database, (¶¶ 63-65, “method 700 receives a statement, request or query from a user… for example, accessing data from a cache in an execution node, retrieving data from a remote storage device, updating data in a cache, storing data in a remote storage device, and the like”)
wherein the tiered database comprises a data warehouse, a proxy layer, and a relational layer; and (¶¶ 24, 26, 34, 52-54, 72, “multiple databases” comprise a data warehouse, “multiple virtual warehouses” comprise a cache/relational layer and a resource manager is a proxy layer using metadata for optimizing a received query)
wherein the database query corresponds to obtained data stored in the data warehouse; (¶¶ 34, 63-65, query is directed to a storage where requested data is processed efficiently)
wherein the relational layer stores a copy of a subset of the obtained data; and (¶ 31, cache layers store a copy of subset of data: “Some nodes may have already cached the data needed to process the query and, therefore, are good candidates for processing the query”)
wherein the subset of the obtained data comprises entries stored in the data warehouse within a certain period of recency; (¶¶ 31, 72, recently accessed data is cached: “the most frequently accessed data is stored in the memory and the least frequently accessed data is stored in the hard disk drive… a least-recently used (LRU) algorithm is utilized to manage the storage of data in the multiple storage devices”)
determining a preliminary query plan to respond to the database query; (¶ 34, “SQL optimizer 214 determines the best method to execute queries based on the data that needs to be processed. SQL optimizer 214 also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of executing the SQL query. SQL executor 216 executes the query code for queries received by resource manager 102”)
recovering, from a collection of relational metadata stored in the proxy layer, a set of database metrics, for the tiered database, derived from the obtained data, (¶ 26, metadata is used for running a query: “metadata…is associated with the entirety of data stored throughout data processing platform 100…metadata 110 includes a summary of data stored in remote data storage systems as well as data available from a local cache…metadata 110 may include information regarding how data is organized in the remote data storage systems and the local caches. Metadata 110 allows systems and services to determine whether a piece of data needs to be accessed without loading or accessing the actual data from a storage device”)
wherein the set of databases metrics comprises: a first set of database metrics corresponding to the data warehouse; and a second set of database metrics corresponding to the relational layer; (¶ 26, metadata “is associated with the entirety of data stored throughout data processing platform”)
computing, from the set of database metrics and the preliminary query plan, a storage access cost, wherein the storage access cost comprises an estimate for time required to respond to the database query; and (¶ 26, wherein, “to improve the speed and efficiency of executing the SQL query” suggests an optimized query includes an estimated time for an improved speed and efficiency of executing the query)
routing the database query based on the storage access cost, wherein the database query is routed to the data warehouse when the storage access cost exceeds a predetermined execution time threshold; and (¶ 26, wherein, “to improve the speed and efficiency of executing the SQL query” suggests a query is routed to a storge, a cache or a remote storage based on the access cost. Note that when the storage access cost exceeds a predetermined execution time threshold is a conditional statement that is not necessarily implementable. Furthermore, access cost exceeding/not exceeding a predetermined threshold depends on a design choice for a threshold. For example, a predetermined threshold can be simply an expected short time for processing a query as fast as possible, as in ¶ 31 because the goal of the system is generating a response using cached data: “It is desirable to retrieve as much data as possible from caches within execution platform 112 because the retrieval speed is typically much faster than retrieving data from storage platform”. Evidently, when data is retrieved from a remote storge, the cost of processing the query exceeds an expected short time for processing a query and when data is retrieved from a local cache the cost of processing the query does not exceed an expected short time for processing a query)
the database query is routed to the relational layer when the storage access cost does not exceed the predetermined threshold; (¶ 26, wherein, “to improve the speed and efficiency of executing the SQL query” suggests a query is routed to a storge, a cache or a remote storage based on the access cost. Note that when the storage access cost does not exceed the predetermined execution time threshold is a conditional statement that is not necessarily implementable. Furthermore, access cost exceeding/not exceeding a predetermined threshold depends on a design choice for a threshold. For example, a predetermined threshold can be simply an expected short time for processing a query as fast as possible, as in ¶ 31 because the goal of the system is generating a response using cached data: “It is desirable to retrieve as much data as possible from caches within execution platform 112 because the retrieval speed is typically much faster than retrieving data from storage platform”. Evidently, when data is retrieved from a remote storge, the cost of processing the query exceeds an expected short time for processing a query and when data is retrieved from a local cache the cost of processing the query does not exceed an expected short time for processing a query)
receiving a result to the database query from at least one selected from the group consisting of the data warehouse and the relational layer; and returning the result to the database query to the sender (¶ 64, “Each execution node performs an assigned task and returns a task result to the resource manager…the execution nodes return the task results to the query coordinator. The resource manager receives the multiple task results and creates a statement result at 712, and communicates the statement result to the user”)
CRUANES did not specifically disclose but SHEN discloses wherein the storage access cost is initialized from the preliminary query plan and updated, in real-time, based on: a first cost derived from the first set of database metrics; and a second cost derived from the second set of database metrics. (Abs, “An access plan to process a query to the virtual database is optimized based on the real time system statistics and the real time data source statistics and a response is produced based on the access plan, with improved performance and reduced cost”; ¶ 3)
It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing wherein the storage access cost is initialized from the preliminary query plan and updated, in real-time, based on: a first cost derived from the first set of database metrics; and a second cost derived from the second set of database metrics because doing so would provide for improving both a response time of the query and a cost of processing based on the real-time information.
Claim 13. CRUANES teaches:
A non-transitory computer-readable medium comprising instructions that, when executed, are configured to cause a processor to perform a process for query planning, the process comprising:
receiving, from a sender, a database query made to a tiered database, (¶¶ 63-65, “method 700 receives a statement, request or query from a user… for example, accessing data from a cache in an execution node, retrieving data from a remote storage device, updating data in a cache, storing data in a remote storage device, and the like”)
wherein the tiered database comprises a data warehouse, a proxy layer, and a relational layer; and (¶¶ 24, 26, 34, 52-54, 72, “multiple databases” comprise a data warehouse, “multiple virtual warehouses” comprise a cache/relational layer and a resource manager is a proxy layer using metadata for optimizing a received query)
wherein the database query corresponds to obtained data stored in the data warehouse; (¶¶ 34, 63-65, query is directed to a storage where requested data is processed efficiently)
wherein the relational layer stores a copy of a subset of the obtained data; and (¶ 31, cache layers store a copy of subset of data: “Some nodes may have already cached the data needed to process the query and, therefore, are good candidates for processing the query”)
wherein the subset of the obtained data comprises entries stored in the data warehouse within a certain period of recency; (¶¶ 31, 72, recently accessed data is cached: “the most frequently accessed data is stored in the memory and the least frequently accessed data is stored in the hard disk drive… a least-recently used (LRU) algorithm is utilized to manage the storage of data in the multiple storage devices”)
determining a preliminary query plan to respond to the database query; (¶ 34, “SQL optimizer 214 determines the best method to execute queries based on the data that needs to be processed. SQL optimizer 214 also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of executing the SQL query. SQL executor 216 executes the query code for queries received by resource manager 102”)
recovering, from a collection of relational metadata stored in the proxy layer, a set of database metrics, for the tiered database, derived from the obtained data; (¶ 26, metadata is used for running a query: “metadata…is associated with the entirety of data stored throughout data processing platform 100…metadata 110 includes a summary of data stored in remote data storage systems as well as data available from a local cache…metadata 110 may include information regarding how data is organized in the remote data storage systems and the local caches. Metadata 110 allows systems and services to determine whether a piece of data needs to be accessed without loading or accessing the actual data from a storage device”)
wherein the set of databases metrics comprises: a first set of database metrics corresponding to the data warehouse; and a second set of database metrics corresponding to the relational layer; (¶ 26, metadata “is associated with the entirety of data stored throughout data processing platform”)
computing, from the set of database metrics and the preliminary query plan, a storage access cost, wherein the storage access cost comprises an estimate for time required to respond to the database query; and (¶ 26, wherein, “to improve the speed and efficiency of executing the SQL query” suggests an optimized query includes an estimated time for an improved speed and efficiency of executing the query)
routing the database query based on the storage access cost, wherein the database query is routed to the data warehouse when the storage access cost exceeds a predetermined execution time threshold; and (¶ 26, wherein, “to improve the speed and efficiency of executing the SQL query” suggests a query is routed to a storge, a cache or a remote storage based on the access cost. Note that when the storage access cost exceeds a predetermined execution time threshold is a conditional statement that is not necessarily implementable. Furthermore, access cost exceeding/not exceeding a predetermined threshold depends on a design choice for a threshold. For example, a predetermined threshold can be simply an expected short time for processing a query as fast as possible, as in ¶ 31 because the goal of the system is generating a response using cached data: “It is desirable to retrieve as much data as possible from caches within execution platform 112 because the retrieval speed is typically much faster than retrieving data from storage platform”. Evidently, when data is retrieved from a remote storge, the cost of processing the query exceeds an expected short time for processing a query and when data is retrieved from a local cache the cost of processing the query does not exceed an expected short time for processing a query)
the database query is routed to the relational layer when the storage access cost does not exceed the predetermined execution time threshold; (¶ 26, wherein, “to improve the speed and efficiency of executing the SQL query” suggests a query is routed to a storge, a cache or a remote storage based on the access cost. Note that when the storage access cost does not exceed the predetermined execution time threshold is a conditional statement that is not necessarily implementable. Furthermore, access cost exceeding/not exceeding a predetermined threshold depends on a design choice for a threshold. For example, a predetermined threshold can be simply an expected short time for processing a query as fast as possible, as in ¶ 31 because the goal of the system is generating a response using cached data: “It is desirable to retrieve as much data as possible from caches within execution platform 112 because the retrieval speed is typically much faster than retrieving data from storage platform”. Evidently, when data is retrieved from a remote storge, the cost of processing the query exceeds an expected short time for processing a query and when data is retrieved from a local cache the cost of processing the query does not exceed an expected short time for processing a query)
receiving a result to the database query from at least one selected from the group consisting of the data warehouse and the relational layer; and returning the result to the database query to the sender. (¶ 64, “Each execution node performs an assigned task and returns a task result to the resource manager…the execution nodes return the task results to the query coordinator. The resource manager receives the multiple task results and creates a statement result at 712, and communicates the statement result to the user”)
CRUANES did not specifically disclose but SHEN discloses wherein the storage access cost is initialized from the preliminary query plan and updated, in real-time, based on: a first cost derived from the first set of database metrics; and a second cost derived from the second set of database metrics. (Abs, “An access plan to process a query to the virtual database is optimized based on the real time system statistics and the real time data source statistics and a response is produced based on the access plan, with improved performance and reduced cost”; ¶ 3)
It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing wherein the storage access cost is initialized from the preliminary query plan and updated, in real-time, based on: a first cost derived from the first set of database metrics; and a second cost derived from the second set of database metrics because doing so would provide for improving both a response time of the query and a cost of processing based on the real-time information.
Claims 2, 8 and 14 are rejected under 35 U.S.C. 103(a) as being unpatentable over CRUANES and SHEN, in view of Gade et al., “Data Lakehouses: Combining the Best of Data Lakes and Data Warehouses” (Gade).
Claim 2. CRUANES as modified teaches:
The tiered database of claim 1, wherein the data warehouse comprises:
at least one data manipulation language (DML) operation; and (¶¶ 37, 64, wherein data is manipulated in data storages)
a slowly changing dimension (SCD), wherein the SCD maintains entries to the data warehouse, updates the entries, and tracks frequencies of updates for the entries. (¶¶ 37, 64, 72, wherein data is updated in data storages and frequency of updates is tracked by, for example, a least-recently used algorithm)
CRUANES as modified did not specifically disclose but Gade discloses a lakehouse architecture, wherein the lakehouse architecture accesses a data storage entity for unstructured data, processes the unstructured data, and stores the processed data in the data warehouse. (Gade, Abs and sec. 1.2, wherein a Lakehouse architecture is disclosed for “supporting structured and unstructured data and enabling organizations to run analytics, machine learning, and business intelligence on a single platform”)
CRUANES ¶ 62 discloses that “any type of data” can be handled and “data is stored in a structured, optimized format”. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing a lakehouse architecture, wherein the lakehouse architecture accesses a data storage entity for unstructured data, processes the unstructured data, and stores the processed data in the data warehouse because doing so would provide for integrating warehouse system as disclosed by CRUANES with a processing engines in an environment such as a lakehouse as disclosed by Gade for explicitly handling “diverse data types, including structured, semi-structured, and unstructured data, allowing for a unified analysis approach”)
Claims 8 and 14 are rejected under the same rationale.
Claims 3, 9 and 15 are rejected under 35 U.S.C. 103(a) as being unpatentable over CRUANES and SHEN, in view of Wu et al., “Predicting Query Execution Time: Are Optimizer Cost Models Really Unusable?” (Wu).
Claim 3. CRUANES as modified taught the tiered database system of claim 1; CRUANES as modified did not specifically teach but Wu discloses:
wherein the first cost is in a first unit of measurement; wherein the second cost is in a second unit of measurement.(Wu, sec. IV, wherein the optimizer computes a total storage access cost using various units of measurements)
CRUANES ¶ 34, discloses “SQL optimizer 214 determines the best method to execute queries based on the data that needs to be processed. SQL optimizer 214 also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of executing the SQL query”. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing wherein the first cost is in a first unit of measurement; wherein the second cost is in a second unit of measurement because doing so would further provide for optimizing the execution of a query using a desired cost model which uses various parameters/unit of measurements for optimizations for achieving the same predictable result finding the best method to execute queries based on the data that needs to be processed)
Claims 9 and 15 are rejected under the same rationale.
Claims 4-6, 10-12 and 16-18 are rejected under 35 U.S.C. 103(a) as being unpatentable over CRUANES and SHEN, in view of INERSJÖ et al., “Comparing database optimization techniques in PostgreSQL” (INERSJÖ).
Claim 4. CRUANES as modified disclosed the tiered database of claim 1; CRUANES did not specifically disclose but INERSJÖ discloses:
wherein the preliminary query plan follows a tree graph structure comprising a plurality of nodes; wherein each node of the plurality of nodes corresponds to a SQL operation; and wherein nodes at a bottom level of the tree graph structure are configured to return raw rows from the subset of the obtained data. (INERSJÖ, secs. 2.2.2, 2.4.1-24.2, “PostgreSQL is an open-source object-relational database system that uses SQL, and offers features such as foreign keys - reference keys that link tables together - updatable views and more [10]”…The PostgreSQL optimizer creates a query plan for every query it receives…The structure of the planner is a plan tree with plan nodes, in which the leaf nodes of the tree are scan nodes that return rows from a table”)
CRUANES, ¶ 24 discloses that in “the described systems and methods, a data storage system utilizes an SQL (Structured Query Language )-based relational database. However, these systems and methods are applicable to any type of database, and any type of data storage and retrieval platform, using any data storage architecture and using any language to store and retrieve data within the data storage and retrieval platform”. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing the preliminary query plan follows a tree graph structure comprising a plurality of nodes; each node of the plurality of nodes corresponds to a SQL operation; and nodes at a bottom level of the tree graph structure are configured to return raw rows from the subset of the obtained data because doing so would further provide for utilizing an open-source object-relational database system that uses SQL for query optimization by creating a plan tree with plan nodes, in which the leaf nodes of the tree are scan nodes that return rows from a table for achieving the same predictable result of optimizing received queries and determining the best method to execute queries based on the data that needs to be processed)
Claims 10 and 16 are rejected under the same rationale.
Claim 5. The tiered database of claim 4, wherein the result to the database query comprises a materialized view; and wherein the query planner is further configured to store the result to the database query in the relational layer. (INERSJÖ, materialized views are saved to be used)
Claims 11 and 17 are rejected under the same rationale.
Claim 6. The tiered database of claim 1, wherein a database metric of the set of database metrics is:
selected from the group consisting of: a metadata metric, a schema detail, a table statistic, an index statistic, and a system statistic; (CRUANES, ¶¶ 26, 34 metadata includes information associated with the entirety of data stored throughout the system /statistics about the stored data in the system; INERSJÖ, “Heuristics are used to cut out the branches that are unlikely to be optimal and the cost for each node is calculated based on statistics that are represented as histograms. These histograms contain statistics of the existing data on tables, indexes, and distribution of values”)
obtained from an external database ingestor, wherein the external database ingestor utilizes a tree graph structure for computational logic; and (CRUANES, ¶ 67, wherein metadata is obtained from anywhere in the system for update; INERSJÖ, secs. 2.4.1, 2.4.2, a tree graph structure is utilized)
cached on the proxy layer, wherein the set of database metrics is updated on the proxy layer at a set duration. (CRUANES, ¶¶ 26, 34 updated metadata includes information associated with the entirety of data stored throughout the system /statistics about the stored data in the system; INERSJÖ, “The PostgreSQL optimizer can update the statistics by running the ANALYZE command for a query, as well as be improved by implementing supported statistical objects - for multivariate statistics”)
Claims 12 and 18 are rejected under the same rationale.
Response to Amendment and Arguments
Applicant’s arguments with respect to amended claims have been fully considered but are not persuasive for at least the following reasons.
Applicant argues “Cruanes and Shen…do not disclose or suggest … a storage access cost is initialized from the preliminary query plan and updated, in real-time, based on a first cost derived from the first set of database metrics, corresponding to the data warehouse, and a second cost derived from the second set of database metrics, corresponding to the relational layer” because: “independent whether Shen discloses optimizing an access plan based on two types real time statistics, the cited reference does not disclose (1) that the update itself is made in real time; (2) that the respective statistics are used to derive two distinct costs to perform the updates; and (3) that the respective costs correspond to data warehouse-directed metrics and relational layer-directed metrics…regardless of whether multiple statistics are used to update the access plan of Shen, the cited reference does not disclose the use of two distinct statistic-based costs…regardless of whether the cited reference discloses the use of distinct statistics, the respective statistics ( system statistics and data source statistics) do not correspond to the first and second sets of database metrics of claim 1”.
In response: Claim 1 recites “a collection of relational metadata comprising a set of database metrics for a tiered database, wherein the set of database metrics is derived from the obtained data; and wherein the set of database metrics comprises: a first set of database metrics corresponding to the data warehouse; and a second set of database metrics corresponding to the relational layer”. CRUANES discloses using metadata/statistics associated with the entirety of data stored anywhere in the system for retrieving data in response to a query based on efficiency, available resources, and the availability of cached data within the virtual warehouses. Therefore, CRUANES explicitly teaches retrieving data from different storages, e.g., the data warehouse and the relational layer based on the cost of accessing the data from a particular storage. See claim 1 for details. CRUANES did not specifically teach accessing a particular storage for retrieving data based on the real-time metadata/statistics. Shen explicitly uses real time statistics for accessing the data based on the real time statistics related to data in a particular storage: ¶¶ 3, 57, “The real time statistics in the global catalog is synchronized with the global statistics across all platforms of the virtual database system… the DV engine 201 uses the global catalog to optimize the access plan”, ¶¶ 67-68, “the gathering including: fetching, by use of a real time data source statistics collection method mapped for the remote data source, the real time data source statistics on the one or more data source objects from the remote data source that are registered with the virtual database, on parameters regarding priorities for insert-update-delete operations, index priority, and modified rows on the one or more data source objects from the remote data source of the virtual database that have been registered with the virtual database”.
Conclusion
The prior arts made of record in PTO-326 and not relied upon are considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHSEN ALMANI whose telephone number is (571)270-7722. The examiner can normally be reached on M-F, 9:00 to 5:00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ann J. Lo can be reached on 571-272-9767. 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.
/MOHSEN ALMANI/Primary Examiner, Art Unit 2159
Prosecution Insights