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 7/27/2026 has been entered.
Status of Claims
Claims 1-20 are pending of which claims 1, 8 and 15 are in independent form.
Claims 1-20 are rejected under 35 U.S.C. 103.
Response to Arguments
Applicant’s arguments/amendments, see “Remarks”, filed on 7/27/2026, with respect to 35 USC 101 have been fully considered and are persuasive. The 35 USC 101 rejection of claims 1-20 has been withdrawn.
Regrading the prior art:
Applicant's arguments filed 7/27/2026 have been fully considered but they are not persuasive.
Applicant’s Argument:
Applicant argues, on pages 14-16, that the prior art of record does not teach the newly added amendments.
Examiner’s Response:
Examiner respectfully disagrees; more specifically Beitchman discloses, identifying a plurality of database engines for processing the data model (To process queries 102, query engines 120 may submit requests, 104a, 104b, and 104c, to get an optimized query plan for the query 102 from engine independent query plan optimizer 140, in various embodiments. Engine independent query plan optimizer 140 may implement query engine identification 142 to detect or otherwise identify the type of query engine for which the query is to be performed. In some embodiments, query engine identification 142 may identify multiple query engines types for a query (e.g., if queries 102a, 102b, and 102c were sub queries of a single query) in order to perform federated query processing [col. 3, ll. 59, col. 4, ll. 2]), each database engine of the plurality of database engines performing a different type of processing operation on the data model than each other database engine of the plurality of database engines (different configured query engines 120a-120c, wherein query engine 120a processes relational database request, such as SQL queries, while query engine 120b is a non-relational data store that processes scans or other operations for object based on key values [col. 3, ll. 13-58]; engine specific plan generation for different types of processing/query engines, including relational and non-relational database engine [col. 14, ll. 32-64]; also see [col. 7, ll. 24-44], [col. 17, ll. 66-col. 18, ll. 15]).
Applicant’s Argument:
Applicant argues, on pages 16-17, that “Beitchman teaches away from the claimed invention”.
Examiner’s Response:
Examiner respectfully disagrees; Beitchman’s characterization of its optimizer as “engine independent” concerns the intermediate representation used to perform query plan optimization, not a requitement that the underlaying query engine perform identical processing operations. Indeed, Beitchman expressly teaches different engine types by identifying the applicable engine, translating an engine specific initial plan into an engine independent optimization format, and translating an engine specific initial plan into an engine independent optimization format, and translating the optimized plan back into appropriate engine specific format. More specifically see [col. 3, ll. 13-58], [col. 14, ll. 32-64], [col. 7, ll. 24-44], [col. 17, ll. 66-col. 18, ll. 15]. Therefore, Beitchman does not disapprove, or discourage the use of functionally different database engines; rather, its architecture is specifically designed to support optimization across such engines.
The office does not rely on the mere translation of a single optimization into multiple formats as satisfying the claimed “different engine-level optimization”. The newly added section of Beitchman clearly teaches different engine types together with engine specific plan generation/processing functionality please see the cited paragraphs above.
Applicant’s Argument:
Applicant argues, on page 18, that “The Cited References Do Not Teach or Suggest Generating Engine-Level Optimizations "Based on Type of the First Entity”.
Examiner’s Response:
Examiner respectfully disagrees; Beitchman’s cost-based optimizer/data catalog material uses database statistics/cardinality information to optimize query execution. Noh also expressly says different database users may correspond to different numbers of records, resulting in different execution plans and even different join types.
Additionally, Applicant’s arguments that the cited art fails to teach or suggest generation of engine level optimizations “based on type of the first entity” is not persuasive because ot considers the references individually rather than their combined teachings. Beitchman clearly teaches that the user account associated with the submitter of a plan request may be mapped to a default type of query engine, and further teaches that a “user account, client, or other source information” may be mapped to a particular query engine type. Beitchman identified engine types are associated with respective engine specific plan generation nodes that generate initial plans and perform operation identification and rearrangement according to engine specific optimization rules (see above). Additionally Noh teaches, execution plan may differ for different database users even for the same query and that differences associated with such users, including different quantities of record, result in different execution plans and different join types. Therefore, the combined teachings reasonably suggest gerenating engine specific optimizations based both on the characteristics of the data to be processed and information associated with the requesting entity.
Applicant’s Argument:
Applicant argues, on page 19, that “The Articulated Motivation to Combine Is Insufficient”.
Examiner’s Response:
Examiner respectfully disagrees; In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the motivation has been provided for all the references used. The suggest prior art all complement each other and the combination thereof provides a strong teaching of claims 1-20.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Noh; Jaeyun et al. (US 20180349404 A1) [Noh] in view of Chadha; Karan et al. (US 12277117 B1) [Chadha] in view of Beitchman; Marc Howard et al. (US 11055352 B1) [Beitchman] in view of John; Jerry (US 20140046936 A1) [John].
Regarding claims 1, 8, and 15, Noh discloses, a system comprising: at least one hardware processor; and a computer-readable medium storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform operations (See Fig. 11) comprising:
receiving a call to a database from a first entity (he queries provided by different users can include one or more same data entity identifiers, but the entity identifiers can resolve to different data entities that are associated with the different users. In some cases, the different database users may be associated with different numbers of data entity records for a data entity targeted by the query ¶ [0017]. n at least some embodiments, the query processor 122 can be configured to use the database query …. In such an embodiment, the query processor 122 can be configured to generate a hash of the database query 142 and to search the shared execution plan cache 110 for a hashed database query that matches the generated hash of the database query 142 ¶ [0025]);
determining whether the hash of the data model matches a hash stored in an optimization data store (In a particular embodiment, the one or more pre-compiled execution plans are associated with hashes of the one or more database queries. In such an embodiment, the query processor 122 can be configured to generate a hash of the database query 142 and to search the shared execution plan cache 110 for a hashed database query that matches the generated hash of the database query 142 ¶ [0025]. Also see ¶ [0060], [0061], and [0070]);
in response to a determination that the hash of the data model does not match a hash stored in the optimization data store (In at least some embodiments, the query processor 122 can be configured to use the database query 142 to retrieve the pre-compiled execution plan 112 from the shared execution plan cache 110. The shared execution plan cache 110 can comprise one or more pre-compiled execution plans. The one or more pre-compiled execution plans can be associated in the shared execution plan cache with one or more database queries that were previously used to generate the one or more pre-compiled execution plans. For example, the one or more database queries can be stored in the shared execution plan cache 110 as look-up keys that can be used to retrieve pre-compiled execution plans associated with the database queries. The query processor 122 can be configured to compare the database query 142 to the one or more database queries in the shared execution plan cache 110 and to retrieve one of the one or more pre-compiled execution plans associated with a query that matches the database query 142. In the example scenario depicted in FIG. 1, the query processor 122 matches the database query 142 with a database query (not shown) associated with the pre-compiled execution plan 112. In a particular embodiment, the one or more pre-compiled execution plans are associated with hashes of the one or more database queries. In such an embodiment, the query processor 122 can be configured to generate a hash of the database query 142 and to search the shared execution plan cache 110 for a hashed database query that matches the generated hash of the database query 142 ¶ [0025]. Also see ¶ [0060], [0061]. At 350, the multi-user execution plan cache is searched with the compiled execution plan. In at least some embodiments, a database server can comprise multiple query processors capable of processing separate database queries in parallel. For example, the multiple query processors can comprise one or more different processes and/or one or more different threads in a multithreaded execution environment. In such an embodiment, it is possible for one query processor to search the multi-user execution plan cache, not find an execution plan associated with a received query, and proceed to compile an execution plan for the received query. Meanwhile, a separate query processor may complete compilation of an execution plan for the same query (received as part of a separate database query request), and add the compiled execution plan to the multi-user execution plan cache ¶ [0074]-[0079]. Examiner specifies that “does not match a hash”, follows the same logic as compiling an execution plan for the query and storing the plan in the cache; thus, the system performs additional operations in response to determining that the generated hash does not match a stored hash).
However, Noh does not explicitly facilitates using a hash function to generate a hash of the data model; processing the call using the data model by applying each different engine-level optimization to a corresponding database engine.
Chadha discloses, using a hash function to generate a hash of the data model (As discussed further below, stored plan cache 414 is a local in-memory cache (e.g., provided by a given compute service manager instance), which, in an embodiment, includes additional capabilities to improve latency, throughput and reduce cost for at least OLTP style workloads. In an example, query coordinator 250 compiles the query plan once for a certain query hash, stores the compiled plan in stored plan cache 414, and reuses the stored plan for subsequent executions. Thus, stored plan cache 414 is a performance sensitive feature [col. 25, ll. 60-col. 26, ll. 2]);
processing the call using the data model by applying each different engine-level optimization to a corresponding database engine (As discussed further below, stored plan cache 414 is a local in-memory cache (e.g., provided by a given compute service manager instance), which, in an embodiment, includes additional capabilities to improve latency, throughput and reduce cost for at least OLTP style workloads. In an example, query coordinator 250 compiles the query plan once for a certain query hash, stores the compiled plan in stored plan cache 414, and reuses the stored plan for subsequent executions. Thus, stored plan cache 414 is a performance sensitive feature [col., 25, ll. 60-col. 26, ll. 2]).
It would have been obvious to one ordinary skilled in the art at the time of the filing of the present invention to combine the teachings of the cited references because Chadha's system would have allowed Noh to facilitate using a hash function to generate a hash of the data model; processing the call using the data model by applying each different engine-level optimization to a corresponding database engine. The motivation to combine is apparent in the Noh’s reference, because there is a need to improve optimizing the performance of tasks with databases.
However neither Noh nor Chadha explicitly facilitates identifying a plurality of database engines for processing the data model, each database engine of the plurality of database engines performing a different type of processing operation on the data model than each other database engine of the plurality of database engines; each of the plurality of database engines, generating a different engine-level optimization based on a predicted volume of data to be used to process the call using the data model and based on type of the first entity, each different engine-level optimization indicating a change in process flow for a corresponding database engine.
Beitchman discloses, identifying a plurality of database engines for processing the data model (To process queries 102, query engines 120 may submit requests, 104a, 104b, and 104c, to get an optimized query plan for the query 102 from engine independent query plan optimizer 140, in various embodiments. Engine independent query plan optimizer 140 may implement query engine identification 142 to detect or otherwise identify the type of query engine for which the query is to be performed. In some embodiments, query engine identification 142 may identify multiple query engines types for a query (e.g., if queries 102a, 102b, and 102c were sub queries of a single query) in order to perform federated query processing [col. 3, ll. 59, col. 4, ll. 2]), each database engine of the plurality of database engines performing a different type of processing operation on the data model than each other database engine of the plurality of database engines (different configured query engines 120a-120c, wherein query engine 120a processes relational database request, such as SQL queries, while query engine 120b is a non-relational data store that processes scans or other operations for object based on key values [col. 3, ll. 13-58]; engine specific plan generation for different types of processing/query engines, including relational and non-relational database engine [col. 14, ll. 32-64]; also see [col. 7, ll. 24-44], [col. 17, ll. 66-col. 18, ll. 15]); for
each of the plurality of database engines, generating a different engine-level optimization based on a predicted volume of data to be used to process the call using the data model and based on type of the first entity, each different engine-level optimization indicating a change in process flow for a corresponding database engine (FIG. 5 is a sequence diagram for managed execution of queries utilizing a resource planner, according to some embodiments. Query 530 may be received at managed query service control plane 320 which may submit the query 532 to query optimization service 292. Query optimization service 292 may generate an optimized query plant to process the query based on metadata requested 534 and received 536 from data catalog service 280. Query optimization service 292 may determine an optimized query and translate the optimized query into an engine-specific format for the engine implemented at provisioned cluster 510. Query optimization service 292 may then submit the query optimization plan 538 to query tracker 340. Query tracker 340 may obtain a lease 540 on a cluster 542 from resource manager service and then initiate initiate execution of the query 544 according to the optimized query plan at the provisioned cluster 510, sending a query execution instruction to a managed query agent 512 [col. 12, ll. 15-34]. Also see [col. 12, ll. 57-col. 12, ll. 2]. The number and size of the computing clusters 920 in the warm cluster pool 910 can be determined based upon a variety of factors including, but not limited to, historical and/or expected volumes of query requests, the price of the computing resources utilized to implement the computing clusters 920, and/or other factors or considerations, in some embodiments [col. 16, ll. 26-32]. Examiner specifies that optimized query represents: execution steps, join order, scan strategy, execution sequence, which implies change in process flow; additionally examiner specifies that maintaining data as part of data volumes and optimization based on the metadata from the data catalog; metadata is query optimization includes: table statistics, row counts, cardinality estimates, data size, which are all used by optimizer to estimate the volume of data processing by a query).
It would have been obvious to one ordinary skilled in the art at the time of the filing of the present invention to combine the teachings of the cited references because Beitchman's system would have allowed Noh and Chadha to facilitate identifying a plurality of database engines for processing the data model; each of the plurality of database engines, generating a different engine-level optimization based on a predicted volume of data to be used to process the call using the data model and based on type of the first entity, each different engine-level optimization indicating a change in process flow for a corresponding database engine. The motivation to combine is apparent in the Noh and Chadha’s reference, because there is a need for improving techniques that can optimize the performance of a query independent of the type of query engine processing the query.
However, neither one of Noh, Chadha or Beitchman explicitly facilitates identifying a data model to handle the call, the data model identifying a joining of data structures in the database; from a plurality of data models in a data model repository.
John discloses, identifying a data model to handle the call, the data model identifying a joining of data structures in the database (If the score did not exceed the threshold in decision block 310, then the search request and any partial semantics obtained from the user's search request may be applied against a repository of previously defined data models. Accordingly, in a process block 314, results from processing in blocks 304 and 306 may be used to identify previously defined data models (pre-existing data models) stored in the database 20 as candidates that represent the user's search request ¶ [0038]; also see ¶ [0013], [0026]-[0027]);
from a plurality of data models in a data model repository (The search request may be analyzed to identify one or more previously created data models ("pre-existing data models) from the database as candidate data models. The search request may also be used to create a new data model as a candidate, if pre-existing data models are deemed to be not adequate. A data model may be selected from among these candidate data models as a response to the search request and presented for consumption by the user ¶ [0013]. user's search request may be applied against a repository of previously defined data models…, results from processing in blocks 304 and 306 may be used to identify previously defined data models (pre-existing data models) stored in the database 20 as candidates that represent the user's search request. A data model may be defined by data tables from the database 20 and various views made on the referenced data tables. The query(ies) against that database 20 made in process block 306 may be made using fragments identified from the search request. Results from the queries may include references to data tables and views. In process block 314, those data tables and views may then be used to identify any pre-existing data models that reference those data tables and views. The identified pre-existing data models may serve as candidate data models for the search request ¶ [0038]).
It would have been obvious to one ordinary skilled in the art at the time of the filing of the present invention to combine the teachings of the cited references because John's system would have allowed Noh, Chadha, and Beitchman to facilitate identifying a data model to handle the call, the data model identifying a joining of data structures in the database; from a plurality of data models in a data model repository. The motivation to combine is apparent in the Noh, Chadha, and Beitchman’s reference, because there is a need for improving consistencies and cost managing large number for data models.
Regarding claims 2, 9, and 16, the combination of Noh, Chadha, Beitchman, and John discloses, sending a message to the first entity requesting a separate engine-level database optimization for each of the plurality of database engines requesting, [the message including the hash] (Beitchman: FIG. 5 is a sequence diagram for managed execution of queries utilizing a resource planner, according to some embodiments. Query 530 may be received at managed query service control plane 320 which may submit the query 532 to query optimization service 292. Query optimization service 292 may generate an optimized query plant to process the query based on metadata requested 534 and received 536 from data catalog service 280. Query optimization service 292 may determine an optimized query and translate the optimized query into an engine-specific format for the engine implemented at provisioned cluster 510. Query optimization service 292 may then submit the query optimization plan 538 to query tracker 340. Query tracker 340 may obtain a lease 540 on a cluster 542 from resource manager service and then initiate execution of the query 544 according to the optimized query plan at the provisioned cluster 510, sending a query execution instruction to a managed query agent 512 [col. 12, ll. 15-34]. Also see [col. 12, ll. 57-col. 13, ll. 2]);
the message including the hash (Noh: In a particular embodiment, the one or more pre-compiled execution plans are associated with hashes of the one or more database queries. In such an embodiment, the query processor 122 can be configured to generate a hash of the database query 142 and to search the shared execution plan cache 110 for a hashed database query that matches the generated hash of the database query 142 ¶ [0025]. Also see ¶ [0060], [0061], and [0070]).
Regarding claims 3, 10 and 17, the combination of Noh, Chadha, Beitchman, and John discloses, wherein the processing the call includes stitching each different engine-level database optimization to an information access query to be sent to the database (Beitchman: Generating optimized query plan translating the optimized query into engine-specific format [col. 12, ll. 15-34]. Also see [col. 12, ll. 57-col. 12, ll. 2]. Examiner specifies that, a query optimization services generates an optimized query plan and translates the optimized query into an engine-specific format).
Regarding claims 4, 11, and 18, the combination of Noh, Chadha, Beitchman, and John discloses, determining whether a server level database optimization exists for the data model and prioritizing each different engine-level optimization over the server level database optimization if there are any conflicts (Chadha: Check if the plan requires re-compilation due to data dependent optimization [col. 17, ll. 38-47]; determining whether the particular query plan requires re-compilation based on the data dependent optimization comprises: …. determining whether the data property constraint still holds based on the set of data properties, wherein the data property constraint comprises a condition that is met based on a set of source tables or files associated with the particular query plan [col. 23, ll. 35-49]. Examiner specifies that these steps correspond to evaluating and prioritizing different optimization strategies).
Regarding claims 5, 12, and 19, the combination of Noh, Chadha, Beitchman, and John discloses, wherein the database is an in-memory database (Chadha: Perform full compilation Generate a compiled query plan (e.g., a stored plan) and store it in stored plan cache 414 (e.g., local in-memory cache) [col. 17, ll. 51-54]. Also see [col. 22, ll. 4-10], [col., 25, ll. 60-col. 26, ll. 2]).
Regarding claims 6, 13, and 20, the combination of Noh, Chadha, Beitchman, and John discloses, passing the hash and an indication of the first entity to a machine learning model trained by a machine learning algorithm to generate different engine-level optimization based on a predicted volume of data to be used to process the call using the data model and based on type of the first entity (Beitchman: adaptive query optimization and optimization based on metadata from a data catalog service [col. 12, ll. 15-34]. Also see [col. 12, ll. 57-col. 13, ll. 2]. Examiner specifies that the optimization service generates optimized query plans based on metadata received from a data catalog).
Regarding claims 7, and 14, the combination of Noh, Chadha, Beitchman, and John discloses, wherein in response to a determination that the hash of the data model matches a hash stored in the optimization data store: retrieving one or more previously used engine-level database optimizations corresponding to the hash stored in the optimization data store; and processing the call using the data model by applying each previously used different engine-level optimization to a corresponding database engine (Noh: execution plans are stored in shared execution plan cache ¶ [0025]; the cache may be searched using a hashed database query ¶ [0060]-[0061]; when matching execution plan is found, the query processor uses the cached execution plan ¶ [0074]; cache plans can be used for subsequent queries ¶ [0075]. Examiner specifies that these sections clearly teaches: hash match detection; retrieved stored optimizations; reusing cached execution plans).
Conclusion
The examiner requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD S ROSTAMI whose telephone number is (571)270-1980. The examiner can normally be reached Mon-Fri From 9 a.m. to 5 p.m..
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, Boris Gorney can be reached at (571)270-5626. 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.
9/2/2026
/MOHAMMAD S ROSTAMI/Primary Examiner, Art Unit 2154
Prosecution Insights