Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed on 02/04/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: 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”)
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”)
comprises:
a first set of database metrics corresponding to the data warehouse; and (CRUANES, ¶ 26, metadata “is associated with the entirety of data stored throughout data processing platform”)
a second set of database metrics corresponding to the relational layer: and (CRUANES, ¶ 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 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”)
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”)
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”)
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)
route 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 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 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 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, wherein: (¶¶ 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”)
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)
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)
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 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, ¶ 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; (¶ 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) where:
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”)
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”)
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 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 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, wherein: (¶¶ 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”)
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)
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)
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 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, ¶ 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; (¶ 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) where:
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”)
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”)
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 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 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:
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. (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 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 moot in view of the new ground of rejections as provided above.
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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 AM-5 PM, ET.
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 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.
/MOHSEN ALMANI/Primary Examiner, Art Unit 2159