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 .
DETAILED ACTION
This action is response to the application filed on 08/15/2025.
Claims 1-20 are pending in this Office Action in which claims 1-20 are rejected and claims 1, 14 and 19 are independent claims.
Priority
Acknowledged is that this Application claims the benefit of priority from parent Application 18820822 (U.S. Patent 12411846 issued 09/09/2025).
Double Patenting Rejections
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of non-statutory obviousness-type double patenting as being unpatentable over claims 1-14 of U.S. Patent 12411846 (issued 09/09/2025 to the parent application 18820822, filed 08/30/2024). Although the conflicting are not patentably distinct from each other because since the claims of the U.S. Patent 12411846 contain elements of the claims of the instant application, and as such, anticipate the claims of the instant application. The conflicting claims between the instant application and the granted U.S. Patent 12411846 are listed in parallel in below table.
Patent 12411846 claims 1-14
Instant Application claims 1-20
1. A system comprising:
a memory storing executable program code; and
one or more processing units to execute the executable program code to cause the system to:
receive a plurality of database queries;
determine a first set of database queries from the plurality of database queries,
where each of the first set of database queries requests data from a same database table, and
where a first one of the first set of database queries requests data from a first one or more columns of the database table and a second one of the first set of database queries requests data from a second one or more columns of the database table;
merge the first set of database queries into a batch query, the batch query including a subclause respectively associated with each of the first set of database queries,
where each subclause defines a query identifier column populated with an identifier of its respective database query, a subclause associated with the first one of the first set of database queries defines NULL fields for ones of the second one or more columns which are not in the first one or more columns, and a subclause associated with the second one of the first set of database queries defines NULL fields for ones of the first one or more columns which are not in the second one or more columns;
transmit the batch query to a database;
receive a batch query result set from the database;
for each of the first set of database queries, determine a result set from the batch query result set; and
return the result sets for each of the first set of database queries.
2. The system of claim 1,
wherein a first one of the first set of database queries is associated with a first database schema and
wherein a second one of the first set of database queries is associated with a second database schema.
3. The system of claim 1, wherein the plurality of database queries are received from a queue, and the one or more processing units are to execute the executable program code to cause the system to:
remove the first set of database queries from the queue to leave a second plurality of database queries in the queue.
4. The system of claim 3, the one or more processing units to execute the executable program code to cause the system to:
determine a third set of database queries from the second plurality of database queries,
where each of the third set of database queries requests data from a same second database table, and
where a total count of returned records for the third set of database queries is less than the threshold;
merge the third set of database queries into a second batch query;
transmit the second batch query to the database;
receive a second batch query result set from the database;
for each of the third set of database queries, determine a second result set based on the second batch query result set; and
return the second result sets for each of the third set of database queries.
5. The system of claim 1, wherein the plurality of database queries comprise a first queue associated with a first database connection, the one or more processing units to execute the executable program code to cause the system to:
determine a second plurality of database queries of a second queue associated with a second database connection;
determine a third set of database queries from the second plurality of database queries,
where each of the third set of database queries selects from a second same database table;
determine a second count of returned records for each of the third set of database queries;
determine a fourth set of database queries from the third set of database queries,
where a total second count of returned records for the fourth set of database queries is less than the threshold;
determine a second batch query based on the fourth set of database queries;
transmit the second batch query to the database;
receive a second batch query result set from the database;
for each of the fourth set of database queries, determine a second result set based on the second batch query result set; and
return the second result sets for each of the fourth set of database queries.
6. The system of claim 1, wherein transmission of the batch query to the database comprises:
determination that a database connector to the database is available; and
transmission of the batch query to the database via the database connector only if it is determined that the database connector is available.
7. The system of claim 1, where the plurality of database queries comprises the first set of database queries and a second set of database queries, the one or more processing units to execute the executable program code to cause the system to:
successively transmit each of the second set of database queries to the database after reception of the batch query result set from the database.
8. The system of claim 7, wherein the plurality of database queries are received from a queue, and wherein one of the second set of database queries was stored in the queue before one of the first set of database queries was stored in the queue.
9. The system of claim 1, where determination of the first set of database queries comprises determination that a number of the first set of database queries is less than a maximum number of queries to batch.
10. A method comprising:
identifying a plurality of database queries in a queue;
determining a first set of database queries of the plurality of database queries,
where each of the first set of database queries requests data from a same database table, and
where a first one of the first set of database queries requests data from a first one or more columns of the database table and a second one of the first set of database queries requests data from a second one or more columns of the database table;
determining a batch query based on the first set of database queries the batch query including a subclause respectively associated with each of the first set of database queries,
where each subclause defines a query identifier column populated with an identifier of its respective database query, a subclause associated with the first one of the first set of database queries defines NULL fields for ones of the second one or more columns which are not in the first one or more columns, and a subclause associated with the second one of the first set of database queries defines NULL fields for ones of the first one or more columns which are not in the second one or more columns;
transmitting the batch query to a database;
receiving a batch query result set from the database;
for each of the first set of database queries, determine a result set from the batch query result set; and
return the result sets for each of the first set of database queries.
11. The method of claim 10, further comprising:
removing the first set of database queries from the queue to leave a second plurality of database queries in the queue;
determining a third set of database queries from the second plurality of database queries,
where each of the third set of database queries requests data from a same second database table, and
where a total count of returned records for the third set of database queries is less than the threshold;
determining a second batch query based on the third set of database queries; transmitting the second batch query to the database;
receiving a second batch query result set from the database;
for each of the third set of database queries, determining a second result set based on the second batch query result set; and
returning the second result sets for each of the third set of database queries.
12. The method of claim 10,
wherein the plurality of database queries comprises the first set of database queries and a second set of database queries, and
wherein one of the second set of database queries was stored in the queue before one of the first set of database queries was stored in the queue, the method further comprising:
successively transmitting each of the second set of database queries to the database after reception of the batch query result set from the database.
13. One or more non-transitory computer-readable media storing program code that, when executed by a computing system, causes the computing system to perform operations comprising:
receiving a plurality of database queries;
determining a first set of database queries from the plurality of database queries,
where each of the first set of database queries requests data from a same database table,
where a first one of the first set of database queries requests data from a first one or more columns of the database table and a second one of the first set of database queries requests data from a second one or more columns of the database table;
merging the first set of database queries into a batch query, the batch query including a subclause respectively associated with each of the first set of database queries,
where each subclause defines a query identifier column populated with an identifier of its respective database query, a subclause associated with the first one of the first set of database queries defines NULL fields for ones of the second one or more columns which are not in the first one or more columns, and a subclause associated with the second one of the first set of database queries defines NULL fields for ones of the first one or more columns which are not in the second one or more columns;
transmitting the batch query to a database;
receiving a batch query result set from the database;
for each of the first set of database queries, determining a result set from the batch query result set; and
returning the result sets for each of the first set of database queries.
14. The one or more non-transitory computer-readable media storing program code according to claim 13 that, when executed by the computing system, causes the computing system to perform operations comprising:
removing the first set of database queries from the queue to leave a second plurality of database queries in the queue;
determining third set of database queries from the second plurality of database queries,
where each of the third set of database queries requests data from a same second database table;
merging the third set of database queries into a second batch query;
transmitting the second batch query to the database;
receiving a second batch query result set from the database;
for each of the third set of database queries, determining a second result set based on the second batch query result set; and
returning the second result sets for each of the third set of database queries.
1. A system comprising:
a memory storing executable program code; and
one or more processing units to execute the executable program code to cause the system to:
receive a plurality of database queries; determine a first set of database queries from the plurality of database queries,
where each of the first set of database queries requests data from a same database table, and
where a total count of returned records for the first set of database queries is less than a threshold;
merge the first set of database queries into a batch query;
transmit the batch query to a database;
receive a batch query result set from the database;
for each of the first set of database queries, determine a result set from the batch query result set; and
return the result sets for each of the first set of database queries.
2. The system of claim 1,
wherein a first one of the first set of database queries is associated with a first database schema and
wherein a second one of the first set of database queries is associated with a second database schema.
3. The system of claim 2, wherein a third one of the first set of database queries requests data from a first one or more columns of the database table and a fourth one of the first set of database queries requests data from a second one or more columns of the database table.
4. The system of claim 1, wherein the batch query includes a subclause respectively associated with each of the first set of database queries, and each subclause defines a query identifier column populated with an identifier of its respective database query.
5. The system of claim 1, wherein a first one of the first set of database queries requests data from a first one or more columns of the database table and a second one of the first set of database queries requests data from a second one or more columns of the database table.
6. The system of claim 5,
wherein the batch query includes a subclause respectively associated with each of the first set of database queries,
wherein a subclause associated with the first one of the first set of database queries defines NULL fields for ones of the second one or more columns which are not in the first one or more columns, and
wherein a subclause associated with the second one of the first set of database queries defines NULL fields for ones of the first one or more columns which are not in the second one or more columns.
7. The system of claim 1, wherein the plurality of database queries are received from a queue, and the one or more processing units are to execute the executable program code to cause the system to: remove the first set of database queries from the queue to leave a second plurality of database queries in the queue.
8. The system of claim 7, the one or more processing units to execute the executable program code to cause the system to:
determine a third set of database queries from the second plurality of database queries,
where each of the third set of database queries requests data from a same second database table, and
where a total count of returned records for the third set of database queries is less than the threshold;
merge the third set of database queries into a second batch query;
transmit the second batch query to the database;
receive a second batch query result set from the database;
for each of the third set of database queries, determine a second result set based on the second batch query result set; and
return the second result sets for each of the third set of database queries.
9. The system of claim 1, wherein the plurality of database queries comprise a first queue associated with a first database connection, the one or more processing units to execute the executable program code to cause the system to:
determine a second plurality of database queries of a second queue associated with a second database connection;
determine a third set of database queries from the second plurality of database queries,
where each of the third set of database queries selects from a second same database table;
determine a second count of returned records for each of the third set of database queries;
determine a fourth set of database queries from the third set of database queries,
where a total second count of returned records for the fourth set of database queries is less than the threshold;
determine a second batch query based on the fourth set of database queries;
transmit the second batch query to the database;
receive a second batch query result set from the database;
for each of the fourth set of database queries, determine a second result set based on the second batch query result set; and
return the second result sets for each of the fourth set of database queries.
10. The system of claim 1, wherein transmission of the batch query to the database comprises:
determination that a database connector to the database is available; and
transmission of the batch query to the database via the database connector only if it is determined that the database connector is available.
11. The system of claim 1, where the plurality of database queries comprises the first set of database queries and a second set of database queries, the one or more processing units to execute the executable program code to cause the system to: successively transmit each of the second set of database queries to the database after reception of the batch query result set from the database.
12. The system of claim 11, wherein the plurality of database queries are received from a queue, and wherein one of the second set of database queries was stored in the queue before one of the first set of database queries was stored in the queue.
13. The system of claim 1, where determination of the first set of database queries comprises determination that a number of the first set of database queries is less than a maximum number of queries to batch.
14. A method comprising:
identifying a plurality of database queries in a queue;
determining a first set of database queries of the plurality of database queries,
where each of the first set of database queries requests data from a same database table, and
where a total count of returned records for the first set of database queries is less than a threshold;
determining a batch query based on the first set of database queries;
transmitting the batch query to a database;
receiving a batch query result set from the database;
for each of the first set of database queries, determine a result set from the batch query result set; and
return the result sets for each of the first set of database queries.
15. The method of claim 14, wherein a first one of the first set of database queries requests data from a first one or more columns of the database table and a second one of the first set of database queries requests data from a second one or more columns of the database table,
wherein the batch query includes a subclause respectively associated with each of the first set of database queries,
wherein a subclause associated with the first one of the first set of database queries defines NULL fields for ones of the second one or more columns which are not in the first one or more columns, and
wherein a subclause associated with the second one of the first set of database queries defines NULL fields for ones of the first one or more columns which are not in the second one or more columns.
16. The method of claim 14, wherein the batch query includes a subclause respectively associated with each of the first set of database queries, and each subclause defines a query identifier column populated with an identifier of its respective database query.
17. The method of claim 14, further comprising:
removing the first set of database queries from the queue to leave a second plurality of database queries in the queue;
determining a third set of database queries from the second plurality of database queries,
where each of the third set of database queries requests data from a same second database table, and
where a total count of returned records for the third set of database queries is less than the threshold;
determining a second batch query based on the third set of database queries;
transmitting the second batch query to the database;
receiving a second batch query result set from the database;
for each of the third set of database queries, determining a second result set based on the second batch query result set; and
returning the second result sets for each of the third set of database queries.
18. The method of claim 14,
wherein the plurality of database queries comprises the first set of database queries and a second set of database queries, and
wherein one of the second set of database queries was stored in the queue before one of the first set of database queries was stored in the queue, the method further comprising:
successively transmitting each of the second set of database queries to the database after reception of the batch query result set from the database.
19. One or more non-transitory computer-readable media storing program code that, when executed by a computing system, causes the computing system to perform operations comprising:
receiving a plurality of database queries; determining a first set of database queries from the plurality of database queries,
where each of the first set of database queries requests data from a same database table, and
where a total count of returned records for the first set of database queries is less than a threshold merging the first set of database queries into a batch query;
transmitting the batch query to a database;
receiving a batch query result set from the database;
for each of the first set of database queries, determining a result set from the batch query result set; and
returning the result sets for each of the first set of database queries.
20. The one or more non-transitory computer-readable media storing program code according to claim 19 that, when executed by the computing system, causes the computing system to perform operations comprising:
removing the first set of database queries from the queue to leave a second plurality of database queries in the queue;
determining third set of database queries from the second plurality of database queries,
where each of the third set of database queries requests data from a same second database table;
merging the third set of database queries into a second batch query;
transmitting the second batch query to the database;
receiving a second batch query result set from the database;
for each of the third set of database queries, determining a second result set based on the second batch query result set; and
returning the second result sets for each of the third set of database queries.
“Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
Claim Rejections - 35 USC § 102
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 14, 1 and 19 are rejected under 35 U.S.C. 102(a)(2) as anticipated by
Gladwin et al.: “ENFORCEMENT OF MINIMUM QUERY COST RULES REQUIRED FOR ACCESS TO A DATABASE SYSTEM”, (U.S. Patent Application Publication US 20210124744 A1, DATE PUBLISHED 2021-04-29; and DATE FILED 2019-10-28, hereafter “Gladwin").
As per claim 14, Gladwin teaches a method comprising:
identifying a plurality of database queries in a queue (See [0438], the query and/or generated result sets for these non-compliant queries can be queued in a local cache of the analytics system.);
determining a first set of database queries of the plurality of database queries (See [0260], retrieving the result set-based query pricing scheme data for a particular type of the result set of the query based on result set characteristics determined by the query pricing module 880 for the result set of the query. Here the determined set of queries based on pricing data reads on a first set of database queries),
where each of the first set of database queries requests data from a same database table (See [0283], query data indicating access to a same table as the given query utilizing the same and/or similar filtering parameters), and
where a total count of returned records for the first set of database queries is less than a threshold (See [0171], the query processing module utilizes intermediate results and/or values generated in executing a query to determine whether compliance is achieved. In particular, one or more rules of the runtime ruleset can pertain to rules specific to intermediate result sets and/or values, which may not be derivable from a final result of the query. For example, a runtime rule can require that an aggregation, such as an average, must be performed upon at least a threshold minimum number of records. The number of records utilized to generate the resulting average cannot be derived from the value of the average itself. Thus, an intermediate result, corresponding to the set of records utilized to generate the average, must be evaluated to determine if the number of records in this set meets or exceeds the threshold minimum number of records.);
determining a batch query based on the first set of database queries (See [0122], to track payment by the user in accordance costs of performing individual queries set [together] by the billing structure data of one or more data providers. Here the individual queries set performed for all queries in the set reads on the batch of queries performed);
transmitting the batch query to a database (See [0122], to track payment by the user in accordance costs of performing individual queries set [together] by the billing structure data of one or more data providers. Here the individual queries set performed for all queries in the set reads on the batch of queries transmitted to the database for being performed);
receiving a batch query result set from the database (See [0074], The result sets generated in executing these queries can be utilized to generate a query response for transmission back to the corresponding user device);
for each of the first set of database queries, determine a result set from the batch query result set (See [0074], The result sets generated in executing these queries can be utilized to generate a query response for transmission back to the corresponding user device); and
return the result sets for each of the first set of database queries (See [0074], The result sets generated in executing these queries can be utilized to generate a query response for transmission back to the corresponding user device).
As per claim 1, the claim recites a system comprising:
a memory storing executable program code (See Gladwin: [0084], a memory module 222 can store operational instructions); and
one or more processing units to execute the executable program code to cause the system (See Gladwin: [0084], when the operational instructions executed by the processing module that cause the processing module) to execute the operations recited as the steps of the method of the claim 14 and rejected above under 35 U.S.C. 102 as anticipated by Gladwin.
Accordingly, claim 1 is rejected along the same rationale that rejected claim 14.
As per claim 19, OraDWG teaches one or more non-transitory computer-readable media storing program code that, when executed by a computing system, causes the computing system (See Gladwin: [0084], a memory module 222 can store operational instructions that, when executed by the processing module) to perform operations recited as the steps of the method of the claim 14 and rejected above under 35 U.S.C. 102 as anticipated by Gladwin.
Accordingly, claim 19 is rejected along the same rationale that rejected claim 14.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37CPR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 2-13, 15-18 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over
Gladwin et al.: “ENFORCEMENT OF MINIMUM QUERY COST RULES REQUIRED FOR ACCESS TO A DATABASE SYSTEM”, (U.S. Patent Application Publication US 20210124744 A1, DATE FILED 2021-04-29; and DATE PUBLISHED 2019-10-28, hereafter “Gladwin"), in view of
Lane et al.: “Oracle Database Data Warehousing Guide, 10g Release 1 (10.1)”, ( December 2003, Oracle Corporation, hereafter “OraDWG").
As per claim 2, Gladwin does not explicitly teach the system of claim 1, wherein a first one of the first set of database queries is associated with a first database schema and wherein a second one of the first set of database queries is associated with a second database schema.
However, OraDWG teaches the system of claim 1, wherein a first one of the first set of database queries is associated with a first database schema (See Pages 18-64,
SELECT c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_gender = 'M' and c.cust_city = 'San Francisco'
UNION ALL
SELECT c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_gender = 'F' and c.cust_city = 'Los Angeles';
Here the SELECT statements teaches the first set of queries associated with the first schema customers), and
wherein a second one of the first set of database queries is associated with a second database schema (See Pages 18-64,
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 2 AND mv.cust_gender = 'M'
UNION ALL
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 1 AND mv.cust_gender = 'F';
Here the SELECT statements teaches the second set of queries associated with the second schema cust_postal_mv and the schema cust_postal_mv is associated with first schema customers by a materialized view created).
It would have been obvious to one having ordinary skill in the art at the time of the Applicant's invention was made to combine the teaching of OraDWG with Gladwin because OraDWG is dedicated to query rewrites and materialized view creation and Gladwin is dedicated to query processing, and a combined teaching of the references would have enabled Gladwin to utilize materialized view and query rewrites to improve database system performance by more efficient queries and data storage.
As per claim 3, Gladwin in view of OraDWG teaches the system of claim 2, wherein a third one of the first set of database queries requests data from a first one or more columns of the database table and a fourth one of the first set of database queries requests data from a second one or more columns of the database table (See OraDWG: Pages 18-64 and 2-8,
SELECT c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_gender = 'M' and c.cust_city = 'San Francisco'
UNION ALL
SELECT c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_gender = 'F' and c.cust_city = 'Los Angeles';
a rewritten query is as follows:
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 2 AND mv.cust_gender = 'M'
UNION ALL
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 1 AND mv.cust_gender = 'F'; and
the customers table is created with four columns: #cust_id, cust_last_name, cust_city, and cust_state_province; and materialized view cust_postal_mv is created with columns mv.cust_city, mv.cust_postal_code and mv.cust_gender for queries to access the numerous columns).
As per claim 4, Gladwin in view of OraDWG teaches the system of claim 1, wherein the batch query includes a subclause respectively associated with each of the first set of database queries and each subclause defines a query identifier column populated with an identifier of its respective database query (See OraDWG: Pages 18-64 and 24-2,
CREATE MATERIALIZED VIEW cust_postal_mv
ENABLE QUERY REWRITE AS
SELECT 1 AS marker, c.cust_gender, c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_city = 'Los Angeles'
UNION ALL
SELECT 2 AS marker, c.cust_gender, c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_city = 'San Francisco'; and
parallel execution can be seen in DSS and data warehousing
environments. OLTP systems can also benefit from parallel execution during batch
processing and during schema maintenance operations such as creation of indexes.
The average simple DML or SELECT statements that characterize OLTP
applications would not see any benefit from being executed in parallel.
Here each SELECT statement teaches a subquery marked by a marker as identifier for populating data from the columns in the SELECT statements).
As per claim 5, Gladwin in view of OraDWG teaches the system of claim 1, wherein a first one of the first set of database queries requests data from a first one or more columns of the database table and a second one of the first set of database queries requests data from a second one or more columns of the database table (See OraDWG: Page 18-77, Example 18–14 Rewrite Using Equivalence (UNION ALL)
CREATE MATERIALIZED VIEW T1
AS SELECT g.region, g.state, g,city, 0 as gid, SUM(sales) sales
FROM sales_fact f, geog_dim g WHERE f.geog_key = g.geog_key
GROUP BY g.region, g.state, g.city;
CREATE MATERIALIZED VIEW T2 AS
SELECT region, state, SUM(sales) sales
FROM T1 GROUP BY region, state;
CREATE VIEW T3 AS
SELECT region, SUM(sales) sales
FROM T2 GROUP BY region;
Here T1, T2 and T3 teaches or reads on the tables providing columns for the set of queries by query statements SELECTs).
As per claim 6, Gladwin in view of OraDWG teaches the system of claim 5,
wherein the batch query includes a subclause respectively associated with each of the first set of database queries (See OraDWG: Page 24-2, parallel execution can be seen in DSS and data warehousing environments. OLTP systems can also benefit from parallel execution during batch processing and during schema maintenance operations such as creation of indexes. The average simple DML or statements that characterize OLTP SELECT applications would not see any benefit from being executed in parallel. ),
wherein a subclause associated with the first one of the first set of database queries defines NULL fields for ones of the second one or more columns which are not in the first one or more columns (See OraDWG: Page 18-77, the ROLLUP(region, state, city) query is then equivalent to:
SELECT * FROM T1 UNION ALL
SELECT region, state, NULL, 1 AS gid, sales FROM T2 UNION ALL
SELECT region, NULL, NULL, 3 AS gid, sales FROM T3 UNION ALL
SELECT NULL, NULL, NULL, 7 AS gid, SUM(sales) FROM T3;), and
wherein a subclause associated with the second one of the first set of database queries defines NULL fields for ones of the first one or more columns which are not in the second one or more columns (See OraDWG: Page 18-77, the ROLLUP(region, state, city) query is then equivalent to:
SELECT * FROM T1 UNION ALL
SELECT region, state, NULL, 1 AS gid, sales FROM T2 UNION ALL
SELECT region, NULL, NULL, 3 AS gid, sales FROM T3 UNION ALL
SELECT NULL, NULL, NULL, 7 AS gid, SUM(sales) FROM T3;).
As per claim 7, Gladwin in view of OraDWG teaches the system of claim 1, wherein the plurality of database queries are received from a queue, and the one or more processing units are to execute the executable program code to cause the system to:
remove the first set of database queries from the queue to leave a second plurality of database queries in the queue (See OraDWG: Page 15-20, If the process that is executing DBMS_MVIEW.REFRESH is interrupted or the instance is shut down, any refresh jobs that were executing in job queue processes will be requeued and will continue running. To remove these jobs, use the DBMS_JOB.REMOVE procedure. Here removing a job from job que reads on removing a current one and leaving the next to be processed).
As per claim 8, Gladwin in view of OraDWG teaches the system of claim 7, the one or more processing units to execute the executable program code to cause the system to:
determine a third set of database queries from the second plurality of database queries (See OraDWG: Page 18-64, SELECT c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_gender = 'M' and c.cust_city = 'San Francisco'
UNION ALL
SELECT c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_gender = 'F' and c.cust_city = 'Los Angeles';
The query can be answered using the following materialized view:
CREATE MATERIALIZED VIEW cust_postal_mv
ENABLE QUERY REWRITE AS
SELECT 1 AS marker, c.cust_gender, c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_city = 'Los Angeles'
UNION ALL
SELECT 2 AS marker, c.cust_gender, c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_city = 'San Francisco';
The rewritten query is as follows:
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 2 AND mv.cust_gender = 'M'
UNION ALL
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 1 AND mv.cust_gender = 'F';
Here listed above are three sequenced set of queries, the 3rd is a rewrite of the 1st referencing to the 2nd that created materialized view cust_postal_mv),
where each of the third set of database queries requests data from a same second database table (See OraDWG: Page 18-64, the third set of queries all request data from cust_postal_mv, the same materialized view that reads on a database table), and
where a total count of returned records for the third set of database queries is less than the threshold (See Gladwin: [0171], the query processing module utilizes intermediate results and/or values generated in executing a query to determine whether compliance is achieved. In particular, one or more rules of the runtime ruleset can pertain to rules specific to intermediate result sets and/or values, which may not be derivable from a final result of the query. For example, a runtime rule can require that an aggregation, such as an average, must be performed upon at least a threshold minimum number of records. The number of records utilized to generate the resulting average cannot be derived from the value of the average itself. Thus, an intermediate result, corresponding to the set of records utilized to generate the average, must be evaluated to determine if the number of records in this set meets or exceeds the threshold minimum number of records.);
merge the third set of database queries into a second batch query (See OraDWG: Page 24-22, Parallel DML (merge) uses parallel execution mechanisms to speed up or scale up large DML operations against large database tables and indexes.);
transmit the second batch query to the database (See OraDWG: Pages 16-84 and 24-43, a query with extended GROUP BY is represented as an equivalent UNION ALL and recursively submitted for rewrite optimization. The groupings that cannot be rewritten stay in the last branch of UNION ALL and access the base data instead. Here the set of queries are lack of GROUP BY clause are submitted optionally in batch for processing);
receive a second batch query result set from the database (See OraDWG: Pages 16-84,
The query can be answered using the following materialized view:
CREATE MATERIALIZED VIEW cust_postal_mv
ENABLE QUERY REWRITE AS
SELECT 1 AS marker, c.cust_gender, c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_city = 'Los Angeles'
UNION ALL
SELECT 2 AS marker, c.cust_gender, c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_city = 'San Francisco';
Here the second set queries is submitted and results returned);
for each of the third set of database queries, determine a second result set based on the second batch query result set (See OraDWG: Pages 16-84,
The rewritten query is as follows:
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 2 AND mv.cust_gender = 'M'
UNION ALL
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 1 AND mv.cust_gender = 'F';
Here the third set of queries is submitted for processing pending the determined a second result set based on the second batch query result set); and
return the second result sets for each of the third set of database queries (See OraDWG: Pages 16-84,
The rewritten query is as follows:
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 2 AND mv.cust_gender = 'M'
UNION ALL
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 1 AND mv.cust_gender = 'F';
Here the third set of queries is submitted for processing pending the determined a second result set based on the second batch query result set).
As per claim 9, Gladwin in view of OraDWG teaches the system of claim 1, wherein the plurality of database queries comprise a first queue associated with a first database connection, the one or more processing units to execute the executable program code to cause the system to:
determine a second plurality of database queries of a second queue associated with a second database connection (See OraDWG: Pages 15-20 and 16-84, Job queues can be used to refresh multiple materialized views in parallel and the query can be answered using the following materialized view:
CREATE MATERIALIZED VIEW cust_postal_mv
ENABLE QUERY REWRITE AS
SELECT 1 AS marker, c.cust_gender, c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_city = 'Los Angeles'
UNION ALL
SELECT 2 AS marker, c.cust_gender, c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_city = 'San Francisco';
Here the second set queries is submitted and results returned);
determine a third set of database queries from the second plurality of database queries (See The query can be answered using the following materialized view:
CREATE MATERIALIZED VIEW cust_postal_mv
ENABLE QUERY REWRITE AS
SELECT 1 AS marker, c.cust_gender, c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_city = 'Los Angeles'
UNION ALL
SELECT 2 AS marker, c.cust_gender, c.cust_city, c.cust_postal_code
FROM customers c
WHERE c.cust_city = 'San Francisco';
Here the second set queries is submitted and results returned);
for each of the third set of database queries, determine a second result set based on the second batch query result set (See OraDWG: Pages 16-84,
The rewritten query is as follows:
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 2 AND mv.cust_gender = 'M'
UNION ALL
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 1 AND mv.cust_gender = 'F';
Here the third set of queries is submitted for processing pending the determined a second result set based on the second batch query result set),
where each of the third set of database queries selects from a second same database table (See OraDWG: Pages 16-84,
The rewritten query is as follows:
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 2 AND mv.cust_gender = 'M'
UNION ALL
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 1 AND mv.cust_gender = 'F';
Here each query of the third set of queries selects from a same second table, the materialized view cust_postal_mv);
determine a second count of returned records for each of the third set of database queries (See Gladwin: [0171], the query processing module utilizes intermediate results and/or values generated in executing a query to determine whether compliance is achieved. In particular, one or more rules of the runtime ruleset can pertain to rules specific to intermediate result sets and/or values, which may not be derivable from a final result of the query. For example, a runtime rule can require that an aggregation, such as an average, must be performed upon at least a threshold minimum number of records. The number of records utilized to generate the resulting average cannot be derived from the value of the average itself. Thus, an intermediate result, corresponding to the set of records utilized to generate the average, must be evaluated to determine if the number of records in this set meets or exceeds the threshold minimum number of records);
determine a fourth set of database queries from the third set of database queries (See Pages 18-42 and 18-43, Every grouping of the original query is placed in a separate UNION ALL branch. The branch will have a simple GROUP BY clause. For example, consider this query:
SELECT p.prod_category, p.prod_subcategory, c.cust_state_province,
t.calendar_month_desc, SUM(s.amount_sold) AS sum_amount_sold
FROM sales s, products p, customers c, times t
WHERE s.prod_id = p.prod_id AND s.cust_id = c.cust_id
GROUP BY GROUPING SETS
((p.prod_subcategory, t.calendar_month_desc),
(t.calendar_month_desc),
(p.prod_category, p.prod_subcategory, c.cust_state_province),
(p.prod_category, p.prod_subcategory));
This is first represented as UNION ALL with four branches:
SELECT null, p.prod_subcategory, null,
t.calendar_month_desc, SUM(s.amount_sold) AS sum_amount_sold
FROM sales s, products p, customers c, times t
WHERE s.prod_id = p.prod_id AND s.cust_id = c.cust_id
GROUP BY p.prod_subcategory, t.calendar_month_desc
How Oracle Rewrites Queries
Query Rewrite 18-43
UNION ALL
SELECT null, null, null,
t.calendar_month_desc, SUM(s.amount_sold) AS sum_amount_sold
FROM sales s, products p, customers c, times t
WHERE s.prod_id = p.prod_id AND s.cust_id = c.cust_id
GROUP BY t.calendar_month_desc
UNION ALL
SELECT p.prod_category, p.prod_subcategory, c.cust_state_province,
null, SUM(s.amount_sold) AS sum_amount_sold
FROM sales s, products p, customers c, times t
WHERE s.prod_id = p.prod_id AND s.cust_id = c.cust_id
GROUP BY p.prod_category, p.prod_subcategory, c.cust_state_province
UNION ALL
SELECT p.prod_category, p.prod_subcategory, null,
null, SUM(s.amount_sold) AS sum_amount_sold
FROM sales s, products p, customers c, times t
WHERE s.prod_id = p.prod_id AND s.cust_id = c.cust_id
GROUP BY p.prod_category, p.prod_subcategory;
Here the queries of the third and fourth UNION ALL reads on the 3rd and 4th sets of queries, respectively),
where a total second count of returned records for the fourth set of database queries is less than the threshold (See Gladwin: [0171], the query processing module utilizes intermediate results and/or values generated in executing a query to determine whether compliance is achieved. In particular, one or more rules of the runtime ruleset can pertain to rules specific to intermediate result sets and/or values, which may not be derivable from a final result of the query. For example, a runtime rule can require that an aggregation, such as an average, must be performed upon at least a threshold minimum number of records. The number of records utilized to generate the resulting average cannot be derived from the value of the average itself. Thus, an intermediate result, corresponding to the set of records utilized to generate the average, must be evaluated to determine if the number of records in this set meets or exceeds the threshold minimum number of records);
determine a second batch query based on the fourth set of database queries (See OraDWG: Page 24-2, parallel execution can be seen in DSS and data warehousing environments. OLTP systems can also benefit from parallel execution during batch processing and during schema maintenance operations such as creation of indexes. The average simple DML or statements that characterize OLTP SELECT applications would not see any benefit from being executed in parallel.);
transmit the second batch query to the database (See OraDWG: Pages 16-84 and 24-43, a query with extended GROUP BY is represented as an equivalent UNION ALL and recursively submitted for rewrite optimization. The groupings that cannot be rewritten stay in the last branch of UNION ALL and access the base data instead. Here the set of queries are lack of GROUP BY clause are submitted optionally in batch for processing);
receive a second batch query result set from the database (See OraDWG: Page 24-2, parallel execution can be seen in DSS and data warehousing environments. OLTP systems can also benefit from parallel execution during batch processing and during schema maintenance operations such as creation of indexes. The average simple DML or statements that characterize OLTP SELECT applications would not see any benefit from being executed in parallel.));
for each of the fourth set of database queries, determine a second result set based on the second batch query result set (See OraDWG: Pages 16-84,
The rewritten query is as follows:
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 2 AND mv.cust_gender = 'M'
UNION ALL
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 1 AND mv.cust_gender = 'F';
Here the third set of queries is submitted for processing pending the determined a second result set based on the second batch query result set); and
return the second result sets for each of the fourth set of database queries (See OraDWG: Pages 16-84,
The rewritten query is as follows:
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 2 AND mv.cust_gender = 'M'
UNION ALL
SELECT mv.cust_city, mv.cust_postal_code
FROM cust_postal_mv mv
WHERE mv.marker = 1 AND mv.cust_gender = 'F';
Here the third set of queries is submitted for processing pending the determined a second result set based on the second batch query result set).
As per claim 10, Gladwin in view of OraDWG teaches the system of claim 1, wherein transmission of the batch query to the database comprises:
determination that a database connector to the database is available (See OraDWG: Page 12-11, below SQL scripts creates local table and populates data from remote database source by connecting to the schema of the remote database in which database available for connection is determined before creating local table:
CREATE TABLE country_city AS SELECT distinct t1.country_name, t2.cust_city
FROM countries@source_db t1, customers@source_db t2
WHERE t1.country_id = t2.country_id
AND t1.country_name='United States of America';); and
transmission of the batch query to the database via the database connector only if it is determined that the database connector is available (See OraDWG: Pages 16-84 and 24-43, a query with extended GROUP BY is represented as an equivalent UNION ALL and recursively submitted for rewrite optimization. The groupings that cannot be rewritten stay in the last branch of UNION ALL and access the base data instead. Here the set of queries are lack of GROUP BY clause are submitted optionally in batch for processing).
As per claim 11, Gladwin in view of OraDWG teaches the system of claim 1, where the plurality of database queries comprises the first set of database queries and a second set of database queries, the one or more processing units to execute the executable program code to cause the system to:
successively transmit each of the second set of database queries to the database after reception of the batch query result set from the database (See OraDWG: Pages 16-84 and 24-43, a query with extended GROUP BY is represented as an equivalent UNION ALL and recursively submitted for rewrite optimization. The groupings that cannot be rewritten stay in the last branch of UNION ALL and access the base data instead. Here the set of queries are lack of GROUP BY clause are submitted optionally in batch for processing).
As per claim 12, Gladwin in view of OraDWG teaches the system of claim 11, wherein the plurality of database queries are received from a queue, and wherein one of the second set of database queries was stored in the queue before one of the first set of database queries was stored in the queue (See OraDWG: Page 15-25, If job queues are enabled and there are many materialized views to refresh, it is faster to refresh all of them in a single command than to call them individually.).
As per claim 13, Gladwin in view of OraDWG teaches the system of claim 1, where determination of the first set of database queries comprises determination that a number of the first set of database queries is less than a maximum number of queries to batch (See OraDWG: Page 24-22, running Batch Jobs Batch jobs executed in an OLTP database during off hours have a fixed time window in which the jobs must complete. A good way to ensure timely job completion is to parallelize their operations. As the work load increases, more machine resources can be added; the scaleup property of parallel operations ensures that the time constraint can be met.).
As per claims 15, 16, 17 and 18, the claims recite the method comprising steps recited as the operations performed by the system of the claims 2, 4, (7 and 8) and 11, respectively, and rejected above as under 35 U.S.C. 103 as unpatentable over Gladwin in view of OraDWG.
Accordingly, claims 15, 16, 17 and 18, are rejected along the same rationale that rejected claims 2, 4, (7 and 8) and 11, respectively.
As per claim 20, OraDWG teaches one or more non-transitory computer-readable media storing program code that, when executed by a computing system, causes the computing system (See Gladwin: [0084], a memory module 222 can store operational instructions that, when executed by the processing module) to perform operations recited as the operations performed by the system of the claims 7 and 8 in combination, and rejected above under 35 U.S.C. 103 as unpatentable over Gladwin in view of OraDWG.
Accordingly, claim 20 is rejected along the same rationale that rejected claims 7 and 8 in combination.
Related Prior Arts
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure can be found in the PTO-892 Notice of Reference Cited.
Conclusion
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. SEE MPEP 2141.02 [R-5] VI. PRIOR ART MUST BE CONSIDERED IN ITS ENTIRETY, INCLUDING DISCLOSURES THAT TEACH AWAY FROM THE CLAIMS: A prior art reference must be considered in its entirety, i.e., as a whole, including portions that would lead away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert. denied, 469 U.S. 851 (1984) In re Fulton, 391 F.3d 1195, 1201, 73 USPQ2d 1141, 1146 (Fed. Cir. 2004). >See also MPEP §2123.
In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KUEN S LU whose telephone number is (571)272-4114. The examiner can normally be reached on M-F, 8-19, Mid-Flex 2 hours.
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, Mr. Aleksandr Kerzhner can be reached on 571-270-1760. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
KUEN S LU /Kuen S Lu/
Art Unit 2165
Primary Patent Examiner
July 15, 2026
Prosecution Insights