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 2 June 2026 has been entered.
Information Disclosure Statement
An Information Disclosure Statement (IDS) has not been submitted as of the mailing of the last Office Action dated 4 March 2026. Applicant is reminded of the continuing obligation under 37 CFR 1.56 to timely apprise the Office of any information which is material to patentability of the claims under consideration in this application.
Introductory Remarks
In response to communications filed on 2 June 2026, claims 6, 14, and 21-23 are amended per Applicant's request. Claims 1, 8-9, and 16 are cancelled. No claims were withdrawn. No new claims were added. Therefore, claims 2-7, 10-15, and 17-23 are presently pending in the application, of which claims 21, 22, and 23 are presented in independent form.
The previously raised 112 rejections of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
The previously raised 101 rejection of the pending claims is withdrawn in view of the amendments to the claims.
The previously raised 103 rejection of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
Response to Arguments
Applicant’s arguments filed 2 June 2026 with respect to the 101 rejections of the pending claims (see Remarks, p. 9-11) have been fully considered. For the Office’s own reasons, the amended claims are considered patent eligible, and the 101 rejection has been accordingly withdrawn.
Applicant's arguments filed 2 June 2026 with respect to the 112 rejections of the pending claims (see Remarks, p. 12-14) have been fully considered but they are not persuasive.
Applicant’s arguments are not pertinent to the issue that was raised. Applicant’s arguments are based on a sequence of steps involving executing queries and performing calculations of an expected total execution runtime.
However, the 112 rejection was based on pointing out the illogical sequence of steps of executing a plurality of contact grouping queries followed by calculating an expected total execution runtime “for all contact grouping queries”.
Note that the claim states “executing a plurality of contact grouping queries allocated to the first data processing pipeline…”. This means a first step of contact grouping queries at the first data processing pipeline is executed. The language then recites “calculating…an expected total execution runtime for all contact grouping queries allocated to the first data processing pipeline”, which is “based on cached query execution runtimes”.
Firstly, what are the cached query execution runtimes from? Is this from executing the plurality of queries, or from some other historic query processing steps? If looking within the context of dependent claims 4-5, 7, 12-13, 15, and 19-20, which recite “cache”, it appears to indicate historical queries; however, this is not made clear in the independent claims.
Secondly, do “all contact grouping queries” which were allocated to the first data processing pipeline, include the “plurality of contact grouping queries” that were previously executed? Or were these “contact grouping queries” subsequent queries that were received, e.g., a different set of queries? It appears that the Specification indicates different sessions, yet the claim language does not make this distinction.
Thus, the relationship between “plurality of contact grouping queries allocated to the first data processing pipeline” and “all contact grouping queries” cannot be ascertained.
(Note that also, “plurality” may also include “all”)
This is the core issue raised by the 112 rejection, and Applicant’s arguments do not address this issue.
It appears instead, that the plurality of contact grouping queries pertained to an earlier session, and the subsequent “all contact grouping queries” pertain to a different session. However, they were not necessarily executed by the same first data processing pipeline, as indicated by the claim language of “dynamically adding a new data processing pipeline configured to invoke a virtual data warehouse of the same size as the first virtual data warehouse”. Rather, it appears that the system learned from an earlier session the amount of resources needed, and thus dynamically adds a new data processing pipeline that corresponds to the same amount of resources that was previously utilized. See, e.g., Specification, [0016-0017], e.g., “…as the total number of customers increases, the contact grouping queries of that customer will automatically be reallocated to a data pipeline with an appropriate warehouse size to timely execute the contact grouping queries”.
See also Specification, [0016], where when the average query execution runtime for the query is larger than some threshold, the contact grouping query is dynamically reallocated to a data pipeline that invokes a larger warehouse.
This means that a virtual warehouse of the same size is used to execute the contact grouping queries when, based on a previous session, the contact grouping queries can be executed by this same-sized virtual warehouse, but will dynamically invoke an appropriate-sized warehouse when the same-sized virtual warehouse is not sufficient (thus, the dynamically added warehouse is not of the same size as the first data processing pipeline when the calculation of the expected runtime determines the original-sized virtual warehouse is insufficient). See also, e.g., Specification, [0032], where a contact grouping query overrides its default allocation to a data pipeline based on the average execution runtime exceeding some threshold.
Thus, Applicant is incorrectly conflating embodiment by incorrectly combining elements of previous sessions with current sessions, and then dynamic reallocation of the queries to the proper-sized warehouse. Therefore, Applicant’s arguments are unpersuasive, and the 112 rejection has been modified below to also conform to the newly amended claim language.
Applicant's arguments filed 2 June 2026 with respect to the 103 rejections of the pending claims (see Remarks, p. 14-18) have been fully considered but they are not persuasive.
Applicant’s arguments that Cseri does not disclose adding a new parallel pipeline invoking a warehouse of the same size as claimed (see Remarks, p. 15) is unpersuasive.
Cseri states, for example, in par. [0063], [0075-0076], [0080], and [0087-0088] that the number of virtual warehouses in a particular execution platform is dynamic, such that new virtual warehouses are created when additional processing and/or caching resources are needed. This is in line, for example, in Specification, [0024], in which “as the total number of customers increases, and thus the number of contact grouping queries that need to be executed increases, additional data pipelines can be added to easily handle the increased workload”.
Cseri also discloses in [0122-0123] adding a virtual warehouse for executing the task, e.g., using preexisting virtual warehouses from a pool of virtual warehouses, or generating a new virtual warehouse that includes at least the number of execution nodes specified.
Therefore, because Cseri explicitly discloses the claimed limitations, therefore the rest of Applicant’s arguments with respect to Cseri allegedly disclosing “vertical scaling” different from the purportedly claimed “horizontal scaling” (see Remarks, p. 15-16) is moot.
Applicant’s argument that the additional amended claim language is not disclosed by the prior art (see Remarks, p. 16) is unpersuasive for at least the reasons set forth in the 103 rejection below.
Applicant’s argument that contact grouping data limitations are not non-functional descriptive material (see Remarks, p. 16) is moot, as the Office Action had not stated that “count of contact records for the entity” was nonfunctional descriptive material. Thus, Applicant’s arguments are erroneously directed to rejections that were not made by the Office Action. Rather, the non-functional descriptive material language was in reference to the information pertaining to “contact” and “contact groups”; see, e.g., Final Rejection on page 30-31.
Specification
The disclosure is objected to because of the following informalities: the claim language “calculating an expected total execution runtime, for all contact grouping queries allocated to a specific data pipeline, using for the calculation the average contact grouping query execution runtime for each contact grouping query” is not within the Specification. However, as this appeared in the originally filed claims, and claims as filed in the original specification are part of the disclosure, the Specification is objected to as containing claim disclosing material not found in the remainder of the specification.
Appropriate correction is required.
Claim Objections
Claims 5 and 13 are objected to because of the following informalities: the claims recite updating “a” cache, which should be “the” cache, because they are dependent on claims 4 and 12, respectively, which already recite “a” cache. Appropriate correction is required.
(Claim 20, which recites substantially the same claim limitations as claims 5 and 13, would have also been objected to if its dependency had been on claim 19; however, its dependency was on claim 18 instead, which did not recite “a” cache)
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are: “configured to” in claims 3, 6, 11, 14, and 18; and “means for” in claims 19-20 and 23.
Because this/these claim limitation(s) is/are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are not being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof.
If applicant intends to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to remove the structure, materials, or acts that performs the claimed function; or (2) present a sufficient showing that the claim limitation(s) does/do not recite sufficient structure, materials, or acts to perform the claimed function.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 2-7, 10-15, and 17-23 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 21-23 and dependent claims 6 and 14 recite calculating an expected total execution runtime for all contact grouping queries allocated to the first/respective data processing pipeline.
Specification, [0015] states that queries were executed and their runtime is stored in a cache. However, the claims recite “plurality of contact grouping queries” and the subsequent “all contact grouping queries”, both of which are allocated to the same first data processing pipeline. Whereas the Specification appears to distinguish the earlier-run queries that are used for calculating expected query runtimes for later queries, the claims instead do not distinguish between current and historic queries, i.e., treating the “plurality of contact grouping queries” and “all contact grouping queries” as being part of the same set of queries that were received and allocated to the first data processing pipeline. Therefore, there is a lack of support for the “plurality of contact grouping queries” being part of the same set of queries as “all of the contact grouping queries”, as claimed.
It appears instead, that the plurality of contact grouping queries pertained to an earlier session, and the subsequent “all contact grouping queries” pertain to a different session. However, they were not necessarily executed by the same first data processing pipeline, as indicated by the claim language of “dynamically adding a new data processing pipeline configured to invoke a virtual data warehouse of the same size as the first virtual data warehouse”. Rather, it appears that the system learned from an earlier session the amount of resources needed, resulting in invoking warehouses of a specific size (see, e.g., Specification, [0024]), which could theoretically encompass the same size warehouse as an earlier session. However, this same size is not invoked in response to determining “when the expected total execution runtime exceeds the time interval” indicated in the service level objective; rather, a larger size is invoked (see, e.g., Specification, [0016], where the contact grouping query is dynamically reallocated to a data pipeline that invokes a larger warehouse when the query execution runtime exceeds a threshold).
More specifically, Specification, [0016], further states that when the average query execution runtime for the query is significantly greater than some threshold, “the contact grouping query may be dynamically reallocated to a data pipeline that invokes a larger warehouse”. In other words, what is supported is that when the expected total execution runtime exceeds a time interval, a larger warehouse is invoked, not a same-sized warehouse (i.e., as the expected total execution runtime indicates that the first virtual data warehouse of that particular size is insufficient to execute the queries within the specified timeframe).
Therefore, the claim language that “invoking a virtual data warehouse of a first size and executing a plurality of contact grouping queries allocated to the first data processing pipeline”, “calculating…an expected total execution runtime for all contact grouping queries allocated to the first data processing pipeline”, and “when the expected total execution runtime exceeds the time interval indicated in the service level objective, dynamically adding a new data processing pipeline configured to invoke a virtual data warehouse of the same size as the first virtual data warehouse”, in this particular claimed combination, are not supported by the Specification, as they incorrectly combine various embodiments with different contexts.
The rest of the dependent claims are rejected for at least by virtue of their dependency on their respective independent claims, and for failing to cure the deficiencies of their respective independent claims.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-7, 10-15, and 17-23 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claims 21-23 and dependent claims 6 and 14 recite calculating an expected total execution runtime for all contact grouping queries allocated to the first/respective data processing pipeline.
It is unclear from the claims the relationship between “plurality of contact grouping queries” and “all contact grouping queries”. Because the plurality of contact grouping queries has already been executed, it cannot be ascertained from the claims whether they claimed as being distinct or a subset of “all contact grouping queries” that were allocated to the first data processing pipeline.
However, the claims recite “plurality of contact grouping queries” and the subsequent “all contact grouping queries”, both of which are allocated to the same first data processing pipeline. Whereas the Specification appears to distinguish the earlier-run queries that are used for calculating expected query runtimes for later queries, the claims instead do not distinguish between current and historic queries, i.e., treating the “plurality of contact grouping queries” and “all contact grouping queries” as being part of the same set of queries that were received and allocated to the first data processing pipeline.
It appears instead, that the plurality of contact grouping queries pertained to an earlier session, and the subsequent “all contact grouping queries” pertain to a different session. However, they were not necessarily executed by the same first data processing pipeline, as indicated by the claim language of “dynamically adding a new data processing pipeline configured to invoke a virtual data warehouse of the same size as the first virtual data warehouse”. Rather, it appears that the system learned from an earlier session the amount of resources needed, and thus dynamically adds a new data processing pipeline that corresponds to the same amount of resources that was previously utilized. See, e.g., Specification, [0016-0017].
Therefore, the metes and bounds of “plurality of contact grouping queries” relative to “all contact grouping queries” cannot be established within the context of the claimed invention.
For purposes of examination, the interpretation that the plurality of contact grouping queries are, e.g., historical contact grouping queries separate from “all contact grouping queries”, has been taken.
Furthermore, the independent claims recite “when the expected total execution runtime exceeds the time interval indicated in the service level objective, dynamically adding a new data processing pipeline configured to invoke a virtual data warehouse of the same size as the first virtual data warehouse”. However, Specification, [0016], states that when the average query execution runtime for the query is significantly greater than some threshold, “the contact grouping query may be dynamically reallocated to a data pipeline that invokes a larger warehouse”. In other words, what is supported is that when the expected total execution runtime exceeds a time interval, a larger warehouse is invoked, not a same-sized warehouse (i.e., as the expected total execution runtime indicates that the first virtual data warehouse of that particular size is insufficient to execute the queries within the specified timeframe). Thus, it does not make sense to invoke the exactly same size when it was already determined the same size virtual warehouse cannot handle the load.
For purposes of examination, the interpretation that the virtual data warehouse of the same size is invoked when it can run the set of contact grouping queries has been taken; and that the virtual data warehouse of the appropriate/specific size is invoked when the expected execution runtime exceeds a threshold, has been taken, as consistent with the Specification.
Furthermore, the independent claims recite “calculating, based on cached query execution runtimes, an expected total execution runtime for all contact grouping queries allocated to the first data processing pipeline”. It is unclear from this language what query execution runtimes, e.g., from where, this is derived from. According to Specification, [0015], it appears to be based on previous/historical queries, e.g., perhaps the claimed “plurality of contact grouping queries” that were previously executed. However, as noted previously, the claim language does not appear to distinguish between the “plurality of contact grouping queries” and “all contact grouping queries” allocated to the first data processing pipeline. Therefore, the manner in which this language is claimed is unclear.
For purposes of examination, the interpretation that the historical queries, e.g., “plurality of contact grouping queries” whose execution runtimes were stored (e.g., as supported in Specification, [0015]) has been taken, and that the plurality of contact grouping queries corresponded to an earlier session in which a particular size of a virtual warehouse was invoked, was used for a subsequent execution of contact grouping queries
The rest of the dependent claims are rejected for at least by virtue of their dependency on their respective independent claims, and for failing to cure the deficiencies of their respective independent claims.
Claims 6 and 14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The claims recite “calculating an expected total execution runtime, for all contact grouping queries allocated to a specific respective data processing pipeline…”. The independent claims already recite similar language, though with respect to a “first” data processing pipeline. It is unclear whether this language was intended to expand on the “calculating, based on cached query execution runtimes, an expected total execution runtime for all contact grouping queries allocated to the first data processing pipeline”, or a separate logic applied to another data processing pipeline distinct from the first data processing pipeline.
For purposes of examination, the interpretation that this is an expansion of the independent claims’ calculating an expected total execution runtime, has been taken.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3-4, 7, 11-12, 15, 18-19, and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Gawande et al. (“Gawande”) (US 2018/0060394 A1), in view of Cseri et al. (“Cseri”) (US 2021/0342360 A1).
Regarding claim 3: Gawande as modified teaches The computer-implemented method of claim 21, wherein the predetermined size of the virtual data warehouse that each data pipeline is configured to invoke determines a number of compute resources that the virtual data warehouse service will devote to executing contact grouping queries allocated to the data pipeline (Gawande, [0046], where managed query service 270 may implement resource planner 330 to select available computing resources from pools for execution of queries based on evaluated collected data statistics associated with query execution and determine an estimated number or configuration of computing resources for executing a query within some set of parameters, and then identify which ones of the resources available to execute the query from a pool that may best fit the estimated number/configuration of resources. See Cseri, [0042] and [0046] above with regards to the “virtual warehouse” limitation).
Regarding claim 4: Gawande as modified teaches The computer-implemented method of claim 21, further comprising:
subsequent to executing each contact grouping query to update a contact group table, updating a cache with data to indicate a contact grouping query execution runtime for the contact grouping query (Gawande, [0024], where in addition to generating query results 142, query execution data 116 may be collected and stored as part of query execution history 130, in order to update the resource selection data available for analysis at resource selection 110 with further examples of resource configuration mapped to a performance outcome for a query. See Gawande, [0074], where a historical query model may be maintained that models the performance of queries with different characteristics based on different execution outcomes, e.g., time to complete, cost to complete, resources consumed to complete, etc. See Gawande, [0045], where query history, query execution logs, and other managed query service historical data may be maintained in an internal data store.
See Gawande, [0057-0058], where query model(s) 720 can be generated based on table metadata 752 and updating the query model(s) 720 accordingly. Updates to query model(s) 754 may be performed in response to trigger events, e.g., number of queries processed since the last update, number of new queries processed since the last update, new set of execution data 742 or table metadata 754 received, etc. (i.e., “subsequent to executing the…query to update the…table”)).
Although Gawande does not appear to explicitly state that a “cache” is utilized, Gawande states that an internal data store may maintain such data. Therefore, it would have been obvious to one of ordinary skill in the art to have modified Gawande to utilize caches with the motivation of quickly accessing such information (i.e., since caches provide local memory storage that can return information quickly).
Regarding claim 7: Gawande as modified teaches The computer-implemented method of claim 21, further comprising:
subsequent to executing a first contact grouping query to update a first contact group table, updating a cache with data to indicate the count of contact records for the entity associated with the first contact grouping query (Gawande, [0057-0058], where query model(s) 720 can be generated based on table metadata 752 and updating the query model(s) 720 accordingly. Table metadata may include information describing tables or other data evaluated or searched by queries, such as the number of rows in a table, the number of distinct values in a column, the number of null values in a column, the cardinality of data values in a column, size or number of data blocks in a table, etc. Updates to query model(s) 754 may be performed in response to trigger events, e.g., number of queries processed since the last update, number of new queries processed since the last update, new set of execution data 742 or table metadata 754 received, etc. (i.e., “subsequent to executing the…query to update the…table”). See also Gawande, [0059], where information related to a prior query, such as the number of rows in the access table, may be used to generate feature vectors that create a feature space for performing comparisons with newly received queries. See Gawande, [0045], where query history, query execution logs, and other managed query service historical data may be maintained in an internal data store (i.e., “updating a [storage] with data to indicate the count of…records…associated with the…query”)).
Although Gawande does not appear to explicitly state that a “cache” is utilized, Gawande states that an internal data store may maintain such data. Therefore, it would have been obvious to one of ordinary skill in the art to have modified Gawande to utilize caches with the motivation of quickly accessing historical query information (i.e., since caches provide local memory storage that can return information quickly).
Regarding claim 11: Claim 11 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 12: Claim 12 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 15: Claim 15 recites substantially the same claim limitations as claim 7, and is rejected for the same reasons.
Regarding claim 18: Claim 18 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 19: Claim 19 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 21: Gawande teaches A computer-implemented method for managing contact grouping queries on a Software-as-a-Service (SaaS) platform, the method comprising:
maintaining a plurality of data processing pipelines, each data processing pipeline to invoke, via the cloud-based … service …, a [resource] of a predetermined size to execute … queries to update … tables in the database (Gawande, [0052-0055], where query 530 may be received at managed query service control plane 320, which may submit the query 532 to resource planner 340. Resource planner 340 may analyze the query to determine the optimal cluster to process the query and submit the query to query tracker 340 indicating the selected cluster 536 for execution. The query 538 subsequently has its execution initiated at the selected provisioned cluster 510. The provisioned cluster 510 can generate a query execution plan and execute the query 544 with respect to data set(s) 520 according to the query plan. Note that the cluster 610 may implement nodes with query engines 624 and query engines 632a-n-.
See Gawande, [0077], where the query is evaluated with respect to resource configurations for executing the query, where a computing resource may be selected to execute the query from a plurality of differently configured computing resources that execute queries. The plurality of computing resources may be pre-configured according to query engines of different types, different configuration settings, and/or different sizes (e.g., number of nodes or slots in a cluster).
See Gawande, [0035], where data storage service(s) 230 may include various types of database storage services for storing, querying, and updating data. See Gawande, [0043], where a data set schema may be part of a table definition so that a query engine (executing on a computing resource) may be able to understand the data being queried, and tables or other data are evaluated or searched by queries using table metadata (Gawande, [0057]) (implying that updating data may include updating data stored in those tables).
See Gawande, [0035], where data storage service(s) 230 may be implemented as a network-based service that enables clients 250 to operate a data storage system in a cloud or network computing environment (i.e., “cloud-based…service”));
maintaining a mapping of … queries to sizes of [resources], the mapping of each … query to a size of a [resource] based on a combination of i) a count of … records …, and ii) a query classification for the … query (Gawande, [0024], where query execution data 116 may be collected and stored as part of query execution history 130 in order to update the resource selection data available for analysis at resource selection 110 with further examples of resource configuration mapped to a performance outcome for a query. See also Gawande, [0056], where the system maps different types of queries and resource configurations with different outcomes via query model(s) 754 (i.e., “maintaining a mapping of…queries”). In this way, query model(s) 720 can classify or otherwise identify features to be compared with received queries 702 in order to determine a configuration for executing the query according to a received execution limitation 704. Query model(s) 720 may be generated using many different sources of information, including data evaluated or searched by queries such as the number of rows in a table, number of distinct values in a column, cardinality of data values in a column, size or number of data blocks in a table, etc. (i.e., “a count of records”).
See also Gawande, [0060-0061], where the query and query execution plans may be provided and evaluated using query model(s) 720, which can classify the query based on a feature vector generated for that query, where the resulting classifications may include a number of nodes, slots, containers, or other components for a computing resource as well as the configuration for a query engine, with different types of query engines being implemented by the system to execute queries (i.e., “a query classification for the…query”));
assigning the execution of each … query to a data processing pipeline in the plurality of data processing pipelines based on the mapping (Gawande, [0060-0061], where the query and query execution plans may be provided and evaluated using query model(s) 720, which can classify the query based on a feature vector generated for that query. See Gawande, [0046], where resource planner 330 selects available computing resources from pools for execution of queries based on evaluated collected data statistics associated with query execution and determine an estimated number or configuration of computing resources for executing the query within some set of parameters, and then identify which ones of the resources available to execute the query from a pool may best fit the estimated number/configuration of resources); [and]
… invoking a first virtual data warehouse of a first size and executing a plurality of contact grouping queries allocated to the first data processing pipeline with the first virtual data warehouse to update contact records in contact grouping tables (Gawande, [0052], where resource planner 340 may submit the query to query tracker 340 indicating the selected cluster 536 for execution, and query tracker 340 may then initiate execution of the query 538 at the provisioned cluster 510, sending a query execution instruction to a managed query agent 512. See Gawande, [0039], where network-based requests may include requests for services, e.g., a request to create, read, write, obtain, or modify data in data storage service(s) 240. See Gawande, [0043], where the query pertains to a table, via a data set schema that identifies the field or column data types of a table so that a query engine may be able to understand the data being queried.
Recall from Gawande, [0035], above where data storage service(s) 230 may include various types of database storage services for storing, querying, and updating data. See Gawande, [0043], where a data set schema may be part of a table definition so that a query engine (executing on a computing resource) may be able to understand the data being queried (implying that updating data may include updating data stored in those tables)) … .
Gawande does not appear to explicitly teach maintaining a plurality of contact grouping queries for a plurality of entities, each contact grouping query associated with an entity and each contact grouping query, when executed, to update contact records for the entity in a contact group table stored in a database of a virtual data warehouse service; that the type of query involved pertains to contact grouping queries; that the type of resource pertains to a virtual data warehouse; that the data processing pipeline is invoked according to a predefined schedule; that the type of data pertains to contact records for the entity associated with the contact grouping query; that the invocation of the resource for executing the query is according to a predefined schedule; subsequent to executing the plurality of contact grouping queries according to the predefined schedule, calculating, based on cached query execution runtimes, an expected total execution runtime for all contact grouping queries allocated to the first data processing pipeline; comparing the expected total execution runtime to a time interval associated with a service level objective; and when the expected total execution runtime exceeds the time interval indicated in the service level objective, dynamically adding a new data processing pipeline configured to invoke a virtual data warehouse of the same size as the first virtual data warehouse.
Cseri teaches maintaining a plurality of … queries …, each … query, when executed, to update … records … in a … table stored in a database of a virtual data warehouse service; that the type of resource pertains to a virtual data warehouse (Cseri, [0034], where one or more jobs may be stored in the queue 124, where queue 124. Each one of those jobs may be communicated to the compute service manager 108 to be scheduled and executed. The queue 124 may determine a job to be performed based on a trigger event such as the updating of one or more rows in a table. See Cseri, [0023] and [0027], where the disclosed system automates virtual warehouse management to specify particular virtual warehouse requirements to execute a set of tasks in a given job (i.e., “virtual warehouse service”), and the network-based data warehouse system 102 includes a compute service manager 108 in communication with a database 114 and an execution platform 110 (i.e., “a database of a virtual warehouse service”));
that the data processing pipeline is invoked according to a predefined schedule; that the invocation of the resource for executing the query is according to a predefined schedule (Cseri, [0042], where during typical operation, the network-based data warehouse system 102 processes multiple jobs determined by the compute service manager 108. These jobs are scheduled and managed by the compute service manager 108 to determine when (i.e., “schedule”) and how to execute the job. See also Cseri, [0048], where the task warehouse manager 150 schedules and manages the execution of queries on behalf of a client account. See also Cseri, [0028], where the compute service manager 108 manages clusters of computing services that provide compute resources (also referred to as “virtual warehouses”). See, more particularly, Cseri, [0046], where the job 154, including the multiple discrete tasks, is assigned to a particular virtual warehouse of the execution platform 110 for execution.
Although Cseri does not appear to explicitly state that the schedule is “predefined” as claimed, one of ordinary skill in the art would have found it obvious to modify Cseri to use predefined schedules with the motivation of simplifying scheduling operations and thus potentially requiring less resources for performing such scheduling operations); and
subsequent to executing the plurality of … queries according to the predefined schedule, calculating, based on cached query execution runtimes, an expected total execution runtime for all … queries allocated to the first data processing pipeline; comparing the expected total execution runtime to a time interval associated with a service level objective; and when the expected total execution runtime exceeds the time interval indicated in the service level objective, dynamically adding a new data processing pipeline configured to invoke a virtual data warehouse of the same size as the first virtual data warehouse (Cseri, [0087-0088], where after a history of prior executions has been established (i.e., “subsequent to executing the plurality of queries”), the task warehouse manager analyzes the history to determine a size of a virtual warehouse for executing the task 502. If an execution time, e.g., a total runtime to complete a prior task (i.e., “expected total execution runtime”) is greater/less than a particular percentage of the task interval (i.e., “time interval”), the task warehouse manager increments a vote count for a larger/smaller size of a virtual warehouse to execute the task (respectively). Otherwise, the task warehouse manager increments a vote count of current size of the virtual warehouse that is to execute the task. The task warehouse manager then selects a particular virtual warehouse from the task warehouse pool 402 to execute the task 502 based on a “winner” of the votes from the last X number of prior executions of tasks, e.g., by only considering virtual warehouses with an exact same size as required. See Cseri above with respect to “predefined schedule”.
See Cseri, [0088], where the task warehouse manager 150 may select the particular virtual warehouse from the task warehouse pool 402 by considering virtual warehouses with an exact same size as required (i.e., “invoke a virtual data warehouse of the same size as the first virtual data warehouse”). See also Cseri, [0063], [0075-0076], [0080], and [0122-0123], where new virtual warehouses may be created when additional processing and/or caching resources are needed, e.g., adding a virtual warehouse for executing the task by using preexisting virtual warehouses from the pool of virtual warehouses, or generating a new virtual warehouse that includes at least the required number of execution nodes to execute the task.
See Cseri, [0091] and [0120], where when determining the number of execution nodes to execute the task, the system utilizes a history of sizes of virtual warehouses that previously executed a number of tasks. Information corresponding to history of votes for various size of virtual warehouse and task metadata are cached in memory. Although Cseri does not appear to explicitly state that the history of task executions is also stored in cache, and thus the execution time of the task disclosed in [0087], it would have been obvious to one of ordinary skill in the art to have modified Cseri such that the history of executions is also stored in cache with the motivation of faster access (see, e.g., Cseri, 0042] and [0091] (thus rendering obvious the limitation of calculating the expected total execution runtime “based on cached query execution runtimes…” as claimed).
See Gawande, [0062] and [0074], where computing resource(s) may be selected to execute the first query based, at least in part, on a best performance outcome, e.g., a service level agreement (i.e., “indicated in a service level objective”), i.e., the query execution having execution time limitations, which is a cost-defined limitation to execute the query, including service level agreements).
It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to have combined the teachings of Gawande and Cseri (hereinafter “Gawande as modified”) with the motivation of enabling the automation of virtual warehouse management and increased flexibility via the use of a virtual warehouse, thereby decoupling a requirement for a user to specify particular virtual warehouse requirements to execute a set of tasks in a given job, thereby reducing costs and optimizing query execution for tasks (Cseri, [0023]), utilizing an execution history of prior tasks to more intelligently understand virtual warehouse usage and performance metrics in order to optimize the execution of current and/or future tasks, thereby improving the performance of a computing system by reducing computing resources (e.g., processor, memory cache) that are utilized to execute tasks (Cseri, [0023]), and allowing the execution platform to quickly deploy large amounts of computing resources when needed without being forced to continue paying for those computing resources when they are no longer needed (Cseri, [0063]).
Although Gawande as modified does not appear to explicitly teach that the type of information pertains to “contact” information, e.g., “contact grouping” queries, “contact” records, “contact group” tables, but rather more generically pertaining to queries, records, and tables, the claimed invention does not distinguish over the prior art because the only differences in the claim limitations and the prior art’s disclosure are only found in the nonfunctional descriptive material and are not functionally involved in the steps recited. The selection of certain nodes/pipelines for executing queries, updating and storing data in tables, would have been performed the same regardless of the specific data involved (i.e., contact-related information as claimed, generic data as disclosed by the prior art, or some other data). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See In re Gulack, 703 F.2d 1381, 1385, 217 USPQ2d 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to have referred to Gawande’s teachings in making the claimed invention, because such data does not functionally relate to the steps in the method claimed and because the subjective interpretation of the data does not patentably distinguish the claimed invention over the prior art.
Additionally, although Gawande as modified does not appear to explicitly state that the records are “for the entity”, Gawande discloses in [0037] that a data warehouse service may offer clients a variety of different data management services, such as sales records marketing, management reporting, business process management, etc. Therefore, one of ordinary skill in the art would have been suggested by Gawande’s disclosure to have specific records “for the entity” with the motivation of grouping/organizing a client’s data storage according to a particular client’s needs (Gawande, [0037]).
Regarding claim 22: Claim 22 recites substantially the same claim limitations as claim 21, and is rejected for the same reasons.
Note that Gawande teaches A system comprising: a processor for executing computer-readable instructions; and a memory storage device storing instructions thereon, which, when executed by the processor, cause the system to perform operations comprising [the claimed steps] (Gawande, [0088] and [0100], where the disclosed methods may be implemented by a computer system that includes one or more processors executing program instructions stored on a computer-readable storage medium coupled to the processors, where the processors are capable of executing instructions to perform the claimed steps).
Regarding claim 23: Claim 23 recites substantially the same claim limitations as claim 21, and is rejected for the same reasons.
Claims 2, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Gawande et al. (“Gawande”) (US 2018/0060394 A1), in view of Cseri et al. (“Cseri”) (US 2021/0342360 A1), in further view of Singh et al. (“Singh”) (US 2023/0342356 A1).
Regarding claim 2: Gawande as modified teaches The computer-implemented method of claim 21, but does not appear to explicitly teach wherein a contact grouping query is assigned a query classification of simple, when the contact grouping query does not include a SQL JOIN statement, and a contact grouping query is assigned a query classification of complex, when the contact grouping query does include a SQL JOIN statement.
Singh teaches wherein a contact grouping query is assigned a query classification of simple, when the contact grouping query does not include a SQL JOIN statement, and a contact grouping query is assigned a query classification of complex, when the contact grouping query does include a SQL JOIN statement (Singh, [0052], where an incoming query is classified based on its complexity, which correlates to the resource usage of a query. The system can maintain a separate lane for each category, e.g., a simple lane, a medium lane, and complex lanes, each of which has its share of system computer resources, where each of these lanes can be managed using different policies such that the performance goals for each lane can be met, e.g., simple lane 210 consisting of relatively short duration queries, a fast response time may be important. Thus, queries in the simple lane 210 can be ordered based on their estimated execution time (i.e., queries classified as “simple”); and queries in the complex lane 214 benefit from a higher share of CPU resources and are allocated a larger share of CPU resources (i.e., queries classified as “complex”).
See also Singh, [0053], where the system assesses the complexity of queries, e.g., a query joining multiple small tables might have a high number of nodes and vertices in the directed acyclic graph representing an execution plan, but since the volume of data processed is small, the execution time or complexity of the query might be low. Similarly, a query which joins a few very large tables might have few nodes and edges in the DAG, but since the volume of data is high, the execution time or complexity of the query can be high.
See Gawande, [0024], where a query may be a SQL query, and queries may be formatted according to different query languages, including SQL (see, e.g., Gawande, [0073])).
Although Singh does not appear to explicitly state that the presence of joins automatically classifies the query as “simple” or “complex”, Singh states that the presence of joins may render the query to be classified as “complex”. Therefore, one of ordinary skill in the art would have found it obvious to modify Singh such that the presence of no joins in the query automatically renders it as “simple” with the motivation of performing classification quickly.
Furthermore, although Singh does not appear to explicitly state that the type of query is a SQL statement (and thus, detecting the presence/absence of a JOIN clause, which is a SQL-specific syntax), one of ordinary skill in the art would have found it obvious to modify Singh to explicitly include Gawande’s SQL queries with predictably equivalent operating characteristics, which is that a query is analyzed for join operations, with the motivation of having the system be able to process a popular query language.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Gawande as modified and Singh. Gawande discloses in [0079-0080] that the system may consider various query characteristics for selecting a particular resource configuration to execute a query, including the execution plans for prior queries including the various types of operations selected by the plan to perform the prior queries (i.e., a “join” being a type of “operation”).
Therefore, one of ordinary skill in the art would have been suggested by Gawande’s disclosure to detect the type of operation, such as the “join” operations described by Singh, with the motivation of predicting the complexity of a query accurately in order to build an intelligent workload management system (Singh, [0052]), e.g., better estimation of run times and other metrics can be useful for improving schedulers for computing systems (Singh, [0022]) by intelligently scheduling incoming requests or queries to ensure optimal utilization of computer resources (Singh, [0052]).
Regarding claim 10: Claim 10 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 17: Claim 17 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Claims 5-6, 13-14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gawande et al. (“Gawande”) (US 2018/0060394 A1), in view of Cseri et al. (“Cseri”) (US 2021/0342360 A1), in further view of Salim et al. (“Salim”) (US 2023/0244687 A1).
Regarding claim 5: Gawande as modified teaches The computer-implemented method of claim 4, further comprising:
for a first contact grouping query, calculating [a] contact grouping query execution runtime for a predetermined number of prior contact grouping query executions of the first contact grouping query (Cseri, [0087], where after a history of prior executions has been established after at least an X number of prior executions of prior tasks, the task warehouse manager analyzes the history to determine an execution time (e.g., a total runtime to complete a prior task) being greater/less than a particular percentage of a task interval); and
updating a cache to indicate the average contact grouping query execution runtime for the predetermined number of prior contact grouping query executions of the first contact grouping query (Gawande, [0074], where a historical query model may be maintained that models the performance of queries with different characteristics based on different execution outcomes, e.g., time to complete, cost to complete, resources consumed to complete, etc. See Gawande, [0045], where query history, query execution logs, and other managed query service historical data may be maintained in an internal data store.
Although Gawande does not appear to explicitly state that a “cache” is utilized, Gawande states that an internal data store may maintain such data. Therefore, it would have been obvious to one of ordinary skill in the art to have modified Gawande to utilize caches with the motivation of quickly accessing such information (i.e., since caches provide local memory storage that can return information quickly)).
Gawande as modified does not appear to explicitly teach that the execution runtime for a query is an average query execution runtime.
Salim teaches that the execution runtime for a query is an average query execution runtime (Salim, [0071], where performance measures may indicate one or more processing times corresponding to each of the plurality of different events, which may indicate, for each emulated event of the emulated plurality of different events, a quantity of time taken by a virtual warehouse to complete the emulated event. Such values may be collected and averaged).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Gawande as modified and Salim (hereinafter “Gawande as modified”) with the motivation of better query execution performance (e.g., having numerous samples to calculate an estimated query execution time, e.g., instead of relying on a few data points, may be better, as an average query execution time may be more representative of a particular type of job/task, and thus may be a better predictor of query execution requirements than, e.g., singular data points), since the system may better allocate resources to the task with better predictive information.
Regarding claim 6: Gawande as modified teaches The computer-implemented method of claim 5, further comprising:
calculating an expected total execution runtime, for all contact grouping queries allocated to a specific respective data processing pipeline in the plurality of data processing pipelines, using for the calculation the average contact grouping query execution runtime for each contact grouping query; comparing the expected total execution runtime for all contact grouping queries allocated to the specific respective data processing pipeline to a time interval indicated in a service level objective; and adding a new data processing pipeline configured to invoke a virtual data warehouse that is the same fixed size as the virtual data warehouse that the respective data processing pipeline is configured to invoke (Cseri, [0087], where after a history of prior executions has been established, the task warehouse manager analyzes the history to determine a size of a virtual warehouse for executing the task 502. If an execution time, e.g., a total runtime to complete a prior task (i.e., “expected total execution runtime”) is greater/less than a particular percentage of the task interval (i.e., “time interval”), the task warehouse manager increments a vote count for a larger/smaller size of a virtual warehouse to execute the task (respectively). Otherwise, the task warehouse manager increments a vote count of current size of the virtual warehouse that is to execute the task. The task warehouse manager then selects a particular virtual warehouse from the task warehouse pool 402 to execute the task 502 based on a “winner” of the votes from the last X number of prior executions of tasks, e.g., by only considering virtual warehouses with an exact same size as required.
See Cseri, [0088], where the task warehouse manager 150 may select the particular virtual warehouse from the task warehouse pool 402 by considering virtual warehouses with an exact same size as required (i.e., “invoke a virtual data warehouse of the same size as the first virtual data warehouse”). See also Cseri, [0063], [0075-0076], [0080], and [0122-0123], where new virtual warehouses may be created when additional processing and/or caching resources are needed, e.g., adding a virtual warehouse for executing the task by using preexisting virtual warehouses from the pool of virtual warehouses, or generating a new virtual warehouse that includes at least the required number of execution nodes to execute the task.
See Gawande, [0062] and [0074], where computing resource(s) may be selected to execute the first query based, at least in part, on a best performance outcome, e.g., a service level agreement (i.e., “indicated in a service level objective”), i.e., the query execution having execution time limitations, which is a cost-defined limitation to execute the query, including service level agreements.
See Salim, [0071], with regards to the “average” query execution runtime, where performance measures may indicate one or more processing times corresponding to each of the plurality of different events, which may indicate, for each emulated event of the emulated plurality of different events, a quantity of time taken by a virtual warehouse to complete the emulated event. Such values may be collected and averaged).
Regarding claim 13: Claim 13 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Regarding claim 14: Claim 14 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Regarding claim 20: Claim 20 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IRENE BAKER whose telephone number is (408)918-7601. The examiner can normally be reached M-F 8-5PM PT.
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.
/IRENE BAKER/Primary Examiner, Art Unit 2154
27 August 2026
Prosecution Insights