DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 9/4/2025 has been entered.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. IN202311024718, filed on 03/31/2023.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 9, and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leff et al. (U.S. Publication No.: 20090125920 A1) hereinafter Leff, in view of Dageville et al. (U.S. Patent No.: US 10860450 B1) hereinafter Dageville, and further in view of Budovski et al. (U.S. Publication No.: 20220382744 A1) hereinafter Budovski.
As to claim 1:
Leff discloses:
A method for processing transaction log queries in a heterogeneous database system, the method comprising: creating, by the heterogeneous database system, database connections with each of a plurality of databases [Paragraph 0027 teaches the clients 104 and target servers 106 may be connected via an interconnection means 108. The interconnection means may be any of a wide variety of systems known in the art for allowing distinct systems to communicate electronically. Paragraph 0028 teaches a target server 106 comprises one or more service implementations 110... the service implementation implements a data-query service. Users may query a relational database via service calls to this service.], the heterogeneous database system providing a particular database interface for interacting with each of the plurality of databases [Paragraph 0027 teaches the clients 104 and target servers 106 may be connected via an interconnection means 108. The interconnection means may be any of a wide variety of systems known in the art for allowing distinct systems to communicate electronically… the service implementation implements a data-query service. Users may query a relational database via service calls to this service.];
repeating, by a database middleware component of the heterogeneous database system at least a plurality of times [Paragraph 0035 teaches a middleware system is located at each client 104. In another embodiment of the present invention, a middleware system is located at a location external to, but accessible by, the client. For example, the middleware system may be connected to the interconnection means 108, and clients may communicate with the middleware system via the interconnection means. Paragraph 0076 teaches determining operation 224 may be performed at the target server. Determining operation 224 may repeat some or all of the steps performed at determining operation 206 and/or determining operation 208.]:
receiving by the database middleware component, a request for a database operation from a client device identifying a target database from the plurality of databases for performing the database operation of the request [Paragraph 0036 teaches the procedure request may include one or more parameters. The procedure request 116 may initially be transmitted to the middleware system 114 located at the client, which may in turn retransmit the request. The request may ultimately be received at a service implementation 110 located at a server 106.]; and directing the request to the target database for execution [Paragraph 0028 teaches a target server 106 comprises one or more service implementations 110... the service implementation implements a data-query service. Users may query a relational database via service calls to this service. Paragraph 0036 teaches the request may ultimately be received at a service implementation 110 located at a server 106.];
Leff discloses some of the limitations as set forth in claim 1 but does not appear to expressly disclose the plurality of databases comprising at least a relational database and a key-value store, wherein the database operation is one of an insert operation, an update operation, or a delete operation, storing, by the database middleware component, in a transaction log store that is managed by the middleware component and independent of the plurality of databases, a record comprising information describing a transaction record for the database operation of the request, the transaction log store storing transaction records for database operations requested to be performed on each of the plurality of databases the transaction log store storing transaction records persistently beyond a retention period of at least one of the plurality of databases, receiving, by the heterogeneous database system a transaction log query, the transaction log query specifying an aggregating of information over a plurality of database operations performed by the plurality of databases, the plurality of database operations including database operations performed by the relational database and database operations performed by the key-value store, executing by the database middleware component, the transaction log query, wherein executing the transaction log query comprises retrieving transaction records for the plurality of database operations stored in the transaction log store of the database middleware component, and aggregating the retrieved transaction records to generate result, providing as output the result of execution of the transaction log query based on the execution, the result comprising aggregated information over the plurality of database operations performed by the plurality of databases.
Dageville discloses:
the plurality of databases comprising at least a relational database and a key-value store [Column 5 Lines 59-61 teaches a data storage system may utilize a SQL (Structured Query Language)-based relational database. Column 12 Lines 33-35 teaches a transaction log is stored in a metadata store and/or across one or more of a plurality of shared storage devices in a database platform. Column 23 Lines 48-55 teaches each of a plurality of database deployments may include storage platform 210 having multiple data storage devices 212a, 212b, 212n. Each of the storage platforms 314 across the multiple deployments may store a replica of the database data such that each of the multiple deployments is capable of serving as a primary deployment where updates and queries are executed on the database data. Column 35 Lines 13-16 teaches storing a record of the original execution of the query in a key value store, wherein the record comprises one or more of: Structured Query Language (SQL) text for the query. Note: A metadata store (middleware) including, as part of a shared storage for a plurality of database deployments, a key value store, wherein the databases are relational databases reads on the claims.], wherein the database operation is one of an insert operation, an update operation, or a delete operation [Column 13 Lines 27-33 teaches the queue 204 may determine a job to be performed based on a trigger event such as the failure of a query, ingestion of data, deleting one or more rows in a table, updating one or more rows in a table, a materialized view becoming stale with respect to its source table, a table reaching a predefined clustering threshold indicating the table should be reclustered, and so forth.]; storing, by the database middleware component, in a transaction log store that is managed by the middleware component and independent of the plurality of databases [Column 12 Lines 33-37 teach a transaction log is stored in a metadata store and/or across one or more of a plurality of shared storage devices in a database platform. The transaction log may comprise a listing of all the jobs that have been performed for a client account.] the transaction log store storing transaction records for database operations requested to be performed on each of the plurality of databases [Column 5 Lines 59-61 teaches a data storage system may utilize a SQL (Structured Query Language)-based relational database. Column 12 Lines 33-37 teach a transaction log is stored in a metadata store and/or across one or more of a plurality of shared storage devices in a database platform. The transaction log may comprise a listing of all the jobs that have been performed for a client account. Column 23 Lines 48-55 teaches each of a plurality of database deployments may include storage platform 210 having multiple data storage devices 212a, 212b, 212n. Each of the storage platforms 314 across the multiple deployments may store a replica of the database data such that each of the multiple deployments is capable of serving as a primary deployment where updates and queries are executed on the database data. Note: The transaction log including query jobs associated a plurality of database deployments reads on the claims.]
receiving, by the heterogeneous database system a transaction log query, the transaction log query specifying an aggregating of information over a plurality of database operations performed by the plurality of databases [Column 12 Lines 39-49 teaches the client account may request the transaction log and a filtered transaction log may be generated that omits the query retry attempts and comprises only an indication of the original execution of the query and/or a successful retry attempt for the query. The filtered transaction log may be provided to the client account. In an embodiment, the transaction log comprises a listing of all “external” jobs that were performed based on direct request from the client account and omits all “internal” jobs that are done for improving performance of the database platform and are not received from the client account. Note: A customer requesting (receiving the transaction log query) from a transaction log transaction log data (aggregating of information over a plurality of database operations performed by the plurality of databases) reads on the claims.], the plurality of database operations including database operations performed by the relational database and database operations performed by the key-value store [Column 5 Lines 59-61 teaches a data storage system may utilize a SQL (Structured Query Language)-based relational database. Column 12 Lines 33-35 teaches a transaction log is stored in a metadata store and/or across one or more of a plurality of shared storage devices in a database platform. Column 23 Lines 48-55 teaches each of a plurality of database deployments may include storage platform 210 having multiple data storage devices 212a, 212b, 212n. Each of the storage platforms 314 across the multiple deployments may store a replica of the database data such that each of the multiple deployments is capable of serving as a primary deployment where updates and queries are executed on the database data. Column 35 Lines 13-16 teaches storing a record of the original execution of the query in a key value store, wherein the record comprises one or more of: Structured Query Language (SQL) text for the query. Note: A metadata store (middleware) including, as part of a shared storage for a plurality of database deployments, a key value store included in the relational databases that includes SQL database operations queries (plurality of database operations including database operations performed by the relational database) associated with the key value store reads on the claims.]; executing by the database middleware component, the transaction log query, wherein executing the transaction log query comprises retrieving transaction records for the plurality of database operations stored in the transaction log store of the database middleware component [Column 12 Lines 33-39 teach a transaction log is stored in a metadata store and/or across one or more of a plurality of shared storage devices in a database platform. The transaction log may comprise a listing of all the jobs that have been performed for a client account. The transaction log may include a listing of each query retry attempt for a single query. Column 12 Lines 50-56 teach the client account may request a specialized transaction log that comprises a listing of all external and/or internal jobs the client account wishes to see. In an embodiment, a transaction log is generated that comprises a listing of all attempts to execute a single query, all queries over a time period, all queries directed at certain database data, and so forth. Note: A metadata store shared between a plurality of databases processing (executing) a request for transaction log data, where the requested is for data from the plurality of database deployments reads on the claims.], and aggregating the retrieved transaction records to generate result [Column 12 Lines 33-39 teach a transaction log is stored in a metadata store and/or across one or more of a plurality of shared storage devices in a database platform. The transaction log may comprise a listing of all the jobs that have been performed for a client account. The transaction log may include a listing of each query retry attempt for a single query. Column 12 Lines 50-56 teach the client account may request a specialized transaction log that comprises a listing of all external and/or internal jobs the client account wishes to see. In an embodiment, a transaction log is generated that comprises a listing of all attempts to execute a single query, all queries over a time period, all queries directed at certain database data, and so forth. Note: Retrieving transaction log data based on a request from a user reads on the claims.] and
providing as output the result of execution of the transaction log query based on the execution [Column 12 Lines 33-39 teach a transaction log is stored in a metadata store and/or across one or more of a plurality of shared storage devices in a database platform. The transaction log may comprise a listing of all the jobs that have been performed for a client account. The transaction log may include a listing of each query retry attempt for a single query. Column 12 Lines 50-56 teach the client account may request a specialized transaction log that comprises a listing of all external and/or internal jobs the client account wishes to see. In an embodiment, a transaction log is generated that comprises a listing of all attempts to execute a single query, all queries over a time period, all queries directed at certain database data, and so forth. Note: Retrieving transaction log data based on a request from a user reads on the claims.]
the result comprising aggregated information over the plurality of database operations performed by the plurality of databases [Column 12 Lines 33-39 teach a transaction log is stored in a metadata store and/or across one or more of a plurality of shared storage devices in a database platform. The transaction log may comprise a listing of all the jobs that have been performed for a client account. The transaction log may include a listing of each query retry attempt for a single query. Column 12 Lines 50-56 teach the client account may request a specialized transaction log that comprises a listing of all external and/or internal jobs the client account wishes to see. In an embodiment, a transaction log is generated that comprises a listing of all attempts to execute a single query, all queries over a time period, all queries directed at certain database data, and so forth. Note: Retrieving transaction log data based on a request from a user reads on the claims.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Leff, by incorporating the use of a metadata store that is shared a plurality of database deployments to collect and service request from a transaction log, as taught by Dageville (see Column 5 Lines 59-61, Column 12 Lines 33-35, Column 12 Lines 39-49, Column 23 Lines 48-55, and Column 35 Lines 13-16), because both applications are directed to query processing; incorporating the use of a metadata store that is shared a plurality of database deployments to collect and service request from a transaction log provide a flexible and scalable data warehouse using a new data processing platform (see Dageville Column 5 Lines 44-45).
Leff and Dageville discloses some of the limitations as set forth in claim 1 but does not appear to expressly disclose the transaction log store storing transaction records persistently beyond a retention period of at least one of the plurality of databases.
Budovski discloses:
the transaction log store storing transaction records persistently beyond a retention period of at least one of the plurality of databases [Paragraph 0045 teaches primary and secondary compute node(s) 116, 112 may outsource data to data server(s) 142 (e.g., as opposed to storing data locally) and logs to log storage 170 (e.g., as opposed to storing logs locally). Paragraph 0053 teaches log storage 170 may comprise one or more virtual machines, storage devices, servers, operating systems, applications, services, local processes, remote machines, web services, etc. that may be executed, hosted, and/or stored therein or via one or more other computing devices (e.g., via network(s)). Paragraph 0101 teaches in the example shown in FIG. 3 with three transaction log storage tiers (e.g., local cache (LC), log file receiver (LFR), and long term (LT)), there may be at least three filler threads 316. Note: Using a transaction log storage for long term storage of transaction data that is not stored in computer nodes, wherein transaction log storage 170 is remote from compute nodes (plurality of databases) reads on the claims.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Leff and Dageville, by incorporating using a transaction log storage for long term storage of transaction data that is not stored in computer nodes, wherein transaction log storage 170 is remote from compute nodes (plurality of databases), as taught by Budovski (see Paragraph 0045, 0053, and 0101), because the three applications are directed to transaction processing; incorporating using a transaction log storage for long term storage of transaction data that is not stored in computer nodes, wherein transaction log storage 170 is remote from compute nodes (plurality of databases) improves throughput and reduce strain on (e.g., virtual or physical) storage media (see Budovski Paragraph 0107).
Claims 9 and 15 are similarly rejected because they are similar in scope.
Claim(s) 2, 10, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leff et al. (U.S. Publication No.: 20090125920 A1) hereinafter Leff, in view of Dageville et al. (U.S. Patent No.: US 10860450 B1) hereinafter Dageville, in view of Budovski et al. (U.S. Publication No.: 20220382744 A1) hereinafter Budovski, and in further view of Pederson (U.S. Publication No.: US 20210034477 A1) hereinafter Pederson.
As to claim 2:
Leff, Dageville, and Budovski discloses some of the limitations as set forth in claim 1 but does not appear to expressly disclose wherein the transaction log store is a relational database and the transaction log query is a database query specified in a database query language of the relational database.
Pederson discloses:
The method of claim 1, wherein the transaction log store is a relational database and the transaction log query is a database query specified in a database query language of the relational database [Paragraph 0013 teaches each relational DBMS server 102 (either 102-1 or 102-2) (also referred to as a “database server”) can be used with a remote object store 104 that stores objects 106. Paragraph 0048 teaches a unity server 122 is also provided in the DBMS 101. In other examples, the unity server 122 can be outside of the DBMS 101. The unity server 122 can be implemented using one or more computer nodes. Although shown as separate from the database server 102-1 and 102-2, in other examples, the unity server 122 can be part of one or more database servers. Paragraph 0052 teaches the unity server 122 includes a persistent storage 126 to store a transaction log 128 (also referred to as a recovery log).]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Leff, Dageville, and Budovski, by incorporating the use of a server that stores transaction log that includes sql query information, as taught by Pederson (see Paragraph 0013, 0048, and 0052), because the four applications are directed to query processing; incorporating the use of a server that stores transaction log that includes sql query information improves efficiency in data access (see Pederson Paragraph 0020).
Claims 10 and 16 are similarly rejected because they are similar in scope.
Claim(s) 3, 11, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leff et al. (U.S. Publication No.: 20090125920 A1) hereinafter Leff, in view of Dageville et al. (U.S. Patent No.: US 10860450 B1) hereinafter Dageville, in view of Budovski et al. (U.S. Publication No.: 20220382744 A1) hereinafter Budovski, and in further view of Gurspan (U.S. Publication No.: US 10628394 B1) hereinafter Gurspan,
As to claim 3:
Leff, Dageville, and Budovski discloses some of the limitations as set forth in claim 1 but does not appear to expressly disclose monitoring performance of each of the plurality of databases for a plurality of requests processed by the heterogeneous database system and selecting the target database for directing the request for execution based on the monitored performance.
Gurspan discloses:
The method of claim 1, further comprising: monitoring performance of each of the plurality of databases for a plurality of requests processed by the heterogeneous database system [Column 6 Lines 28-32 teach the database analysis service 104 is a collection of computing resources that operate collectively to process requests to migrate database systems such as the customer database system 108. Column 9 Lines 49-54 teach the database analysis service 304 compares the test results to determine recommended instance types 330 (i.e., the database analysis service 304 compares the database performance test results from the database instance types to the database performance test results from the customer database system).]; and selecting the target database for directing the request for execution based on the monitored performance [Column 6 Lines 28-32 teach the database analysis service 104 is a collection of computing resources that operate collectively to process requests to migrate database systems such as the customer database system 108. Column 10 Lines 42-51 teach if the database analysis service determines that the database instance of the selected database instance type has the same or better data throughput, query speed, concurrency, CPU usage, memory usage, network bandwidth, and/or performance for other database performance metrics as compared to the database system and that the database analysis service should indicate 416 that the database instance type be recommended, the database analysis service, in one embodiment, recommends 418 the database instance type as an instance type suitable for migration.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Leff, Dageville, and Budovski, by incorporating selecting an appropriate database to handle request based on a comparison of various database performance metrics, as taught by Gurspan (see Column 6 Lines 28-32, Column 9 Lines 49-54, and Column 10 Lines 42-51), because the four applications are directed to query processing; incorporating selecting an appropriate database to handle request based on a comparison of various database performance metrics provides the desired performance for a database instance of the database instance type that is identified as a candidate for migration (see Gurspan Column 10 Lines 16-18).
Claims 11 and 17 are similarly rejected because they are similar in scope.
Claim(s) 4, 7, 8, 12-14, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leff et al. (U.S. Publication No.: 20090125920 A1) hereinafter Leff, i in view of Dageville et al. (U.S. Patent No.: US 10860450 B1) hereinafter Dageville, in view of Budovski et al. (U.S. Publication No.: 20220382744 A1) hereinafter Budovski, in view of Gurspan (U.S. Publication No.: US 10628394 B1) hereinafter Gurspan, and further in view of Ganapathi et al. (U.S. Publication No.: US 20100082602 A1) hereinafter Ganapathi.
As to claim 4:
Leff, Dageville, Budovski, and Gurspan discloses some of the limitations as set forth in claim 1 and 3 but does not appear to expressly disclose mapping characteristics of the database operations specified in the requests processed by the heterogeneous database system to performance of each of the plurality of databases; and wherein selecting the target database for directing the request for execution based on the monitored performance comprises, determining characteristics of the request and selecting the target database based on the mapping.
Ganapathi discloses:
The method of claim 3, further comprising: mapping characteristics of the database operations specified in the requests processed by the heterogeneous database system to performance of each of the plurality of databases [Paragraph 0040 teaches for each workload in the training set, one embodiment collects the workload's queries' execution plans as well as the performance results of running the queries in isolation on the database system configuration. Paragraph 0044 teaches this step (in a simple embodiment) produces two maps. One map locates workloads according to their query feature characteristics, and another map locates queries according to their performance characteristics in such a way that two workloads that are co-located on one map will also be co-located on the other map. Paragraph 0045 teaches creates a collocation function (shown as output in block 560) between workload feature characteristics and performance characteristics so that given a location on one map a corresponding location on the other map can be determined. Paragraph 0056 teaches the present invention are not limited to any particular type or number of databases and/or computer systems. Note: Mapping query feature characteristics to performance characteristics for each database in a plurality of database configurations reads on the claims.]; and wherein selecting the target database for directing the request for execution based on the monitored performance comprises, determining characteristics of the request and selecting the target database based on the mapping [Paragraph 0004 teaches databases can more accurately be selected with respect to size, capacity, performance, management, and cost, to name a few examples. Paragraph 0056 teaches in accordance with the present invention are not limited to any particular type or number of databases and/or computer systems. Paragraph 0059 teaches selecting a database system configuration to sell to a customer. The system executes the customer's business workload with at least acceptable performance, yet designs a system to be priced within the customer's budget. Note: Using the mapping to select a database configuration from a plurality of database configurations reads on the claims.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Leff, Dageville, Budovski, and Gurspan, by incorporating selecting an appropriate database to handle request based on a comparison of various database performance metrics associated with a mapping, as taught by Ganapathi (see Paragraph 0004, 0040, 0044, 0045, 0056 and 0059), because the five applications are directed to query processing; incorporating selecting an appropriate database to handle request based on a comparison of various database performance metrics associated with a mapping improves the performance of executing the workload on the database system configuration (see Ganapathi Paragraph 0059).
Claims 12 and 18 are similarly rejected because they are similar in scope.
As to claim 7:
Leff, Dageville, Budovski, Gurspan, and Ganapathi discloses all of the limitations as set forth in claims 1, 3, and 4.
Ganapathi also discloses:
The method of claim 4, further comprising: generating a map from values of a particular characteristic of requests to databases from the plurality of databases [Paragraph 0030 teaches a query performance vector is created from the performance metrics that the database system collects when running the query. Paragraph 0040 teaches for each workload in the training set, one embodiment collects the workload's queries' execution plans as well as the performance results of running the queries in isolation on the database system configuration. Paragraph 0044 teaches this step (in a simple embodiment) produces two maps. One map locates workloads according to their query feature characteristics, and another map locates queries according to their performance characteristics in such a way that two workloads that are co-located on one map will also be co-located on the other map. Paragraph 0045 teaches creates a collocation function (shown as output in block 560) between workload feature characteristics and performance characteristics so that given a location on one map a corresponding location on the other map can be determined. Paragraph 0056 teaches the present invention are not limited to any particular type or number of databases and/or computer systems. Note: Mapping query feature characteristics to performance characteristics for each database in a plurality of database configurations wherein the performance is represented by performance metrics (values) reads on the claims.]; dynamically modifying the map based on changes in performance of the databases [Paragraph 0030 teaches a query performance vector is created from the performance metrics that the database system collects when running the query. Paragraph 0040 teaches for each workload in the training set, one embodiment collects the workload's queries' execution plans as well as the performance results of running the queries in isolation on the database system configuration. Paragraph 0044 teaches this step (in a simple embodiment) produces two maps. One map locates workloads according to their query feature characteristics, and another map locates queries according to their performance characteristics in such a way that two workloads that are co-located on one map will also be co-located on the other map. Paragraph 0045 teaches creates a collocation function (shown as output in block 560) between workload feature characteristics and performance characteristics so that given a location on one map a corresponding location on the other map can be determined. Paragraph 0056 teaches the present invention are not limited to any particular type or number of databases and/or computer systems. Note: Mapping query feature characteristics to performance characteristics for each database in a plurality of database configurations wherein the performance is represented by performance metrics (values) while the query is running (dynamically modifying) reads on the claims.]; and directing requests to databases from the plurality of databases based on the modified map [Paragraph 0004 teaches databases can more accurately be selected with respect to size, capacity, performance, management, and cost, to name a few examples. Paragraph 0056 teaches in accordance with the present invention are not limited to any particular type or number of databases and/or computer systems. Paragraph 0059 teaches selecting a database system configuration to sell to a customer. The system executes the customer's business workload with at least acceptable performance, yet designs a system to be priced within the customer's budget. Note: Using the mapping to select a database configuration from a plurality of database configurations reads on the claims.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Leff, Dageville, Budovski, and Gurspan, by incorporating selecting an appropriate database to handle request based on a comparison of various database performance metrics associated with a mapping, as taught by Ganapathi (see Paragraph 0004, 0030, 0040, 0044, 0045, 0056 and 0059), because the five applications are directed to query processing; incorporating selecting an appropriate database to handle request based on a comparison of various database performance metrics associated with a mapping improves the performance of executing the workload on the database system configuration (see Ganapathi Paragraph 0059).
Claims 13 and 19 are similarly rejected because they are similar in scope.
As to claim 8:
Leff, Dageville, Budovski, Gurspan, and Ganapathi discloses all of the limitations as set forth in claims 1, 3, and 4.
Ganapathi also discloses:
The method of claim 4, further comprising: training a machine learning based model configured to receive as input, features describing requests processed by the heterogeneous database system and predicting resource requirements of the heterogeneous database system [Paragraph 0019 teaches accurately predicts multiple performance metrics (including elapsed time and resource requirements, such as CPU time, disk I/Os, memory usage, and number of messages) simultaneously. Paragraph 0024 teaches machine learning techniques to first derive a model based on a training set of previously executed data points (queries) and their measured performance.]; and executing the machine learning based model to predict resource requirements the heterogeneous database system [Paragraph 0019 teaches accurately predicts multiple performance metrics (including elapsed time and resource requirements, such as CPU time, disk I/Os, memory usage, and number of messages) simultaneously. Paragraph 0022 teaches a machine learning technique or algorithm to find correlations between the query plan properties and query performance metrics on a training set of queries and then use these correlations to predict the performance of new queries.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Leff, Dageville, Budovski, and Gurspan, by incorporating selecting an appropriate database to handle request based on a comparison of various database performance metrics associated with a machine learning model, as taught by Ganapathi (see Paragraph 0019, 0022, and 0024), because the five applications are directed to query processing; incorporating selecting an appropriate database to handle request based on a comparison of various database performance metrics associated with a machine learning model improves the performance of executing the workload on the database system configuration (see Ganapathi Paragraph 0059).
Claims 14 and 20 are similarly rejected because they are similar in scope.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leff et al. (U.S. Publication No.: 20090125920 A1) hereinafter Leff, in view of Dageville et al. (U.S. Patent No.: US 10860450 B1) hereinafter Dageville, in view of Budovski et al. (U.S. Publication No.: 20220382744 A1) hereinafter Budovski, in view of Gurspan (U.S. Publication No.: US 10628394 B1) hereinafter Gurspan, in view of Ganapathi et al. (U.S. Publication No.: US 20100082602 A1) hereinafter Ganapathi, and further in view of Chen et al. (U.S. Patent No.: US 11016969 A1) hereinafter Chen.
As to claim 5:
Leff, Dageville, Budovski, Gurspan, and Ganapathi discloses some of the limitations as set forth in claim 1, 3, and 4 but does not appear to expressly disclose wherein the characteristics of a particular request include size of data processed by the particular request such that requests processing data greater than a threshold size are directed to a particular database.
Chen discloses:
The method of claim 4, wherein the characteristics of a particular request include size of data processed by the particular request such that requests processing data greater than a threshold size are directed to a particular database [Column 13 Line 37 teaches database cluster 330. Column 14 Lines 32-37 teach proxy 340 may then determine whether transactional cluster 320 or analytical cluster 330 is better equipped to handle the query based on a prediction of the data size the query will retrieve and one or more rules, the one or more rules including, for example, a data size threshold, historical performance, and/or database statistics.].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Leff, Dageville, Budovski, Gurspan, and Ganapathi, by incorporating selecting a database cluster to process queries based on a threshold size, as taught by Chen (see Column 13 Line 37 and Column 14 Lines 32-37), because the six applications are directed to query processing; incorporating selecting a database cluster to process queries based on a threshold size provides the most efficient way of producing the result of the query (see Chen Column 15 Lines 40-41).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leff et al. (U.S. Publication No.: 20090125920 A1) hereinafter Leff, in view of Dageville et al. (U.S. Patent No.: US 10860450 B1) hereinafter Dageville, in view of Budovski et al. (U.S. Publication No.: 20220382744 A1) hereinafter Budovski, in view of Gurspan (U.S. Publication No.: US 10628394 B1) hereinafter Gurspan, in view of Ganapathi et al. (U.S. Publication No.: US 20100082602 A1) hereinafter Ganapathi, in view of Chen et al. (U.S. Patent No.: US 11016969 A1) hereinafter Chen, in further view of Safary et al. (U.S. Publication No.: US 20220318648 A1) hereinafter Safary.
As to claim 6:
Leff, Dageville, Budovski, Gurspan, Ganapathi, and Chen discloses some of the limitations as set forth in claim 1, 3, 4, 5 but does not appear to expressly disclose adjusting the threshold size based on monitoring of the performance of each of the plurality of databases for requests.
Safary discloses:
The method of claim 5, further comprising: adjusting the threshold size based on monitoring of the performance of each of the plurality of databases for requests [Paragraph 0133 teaches based on these monitored parameters, the AI-based performance monitoring module 720 may adjust a threshold size of the transaction pool. Paragraph 0160 teaches if resource utilization is determined to be greater than a threshold, a block size may be reduced to enable faster queries of previously generated blocks.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Leff, Dageville, Budovski, Gurspan, Ganapathi, and Chen, by incorporating adjusting a threshold size based on monitored performance, as taught by Safary (see Paragraph 0133 and 0160), because the seven applications are directed to query processing; incorporating adjusting a threshold size based on monitored performance enables faster queries (see Safary Paragraph 0160).
Response to Arguments
Applicant’s arguments with respect to the 103 rejection of claim 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EARL LEVI ELIAS whose telephone number is (571)272-9762. The examiner can normally be reached Monday - Friday (IFP).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sherief Badawi can be reached at 571-272-9782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EARL LEVI ELIAS/Examiner, Art Unit 2169
/SHERIEF BADAWI/Supervisory Patent Examiner, Art Unit 2169