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 .
Claims 1-20 are presented for examination.
The claims and only the claims form the metes and bounds of the invention. “Office personnel are to give claims their broadest reasonable interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). Limitations appearing in the specification but not recited in the claim are not read into the claim. In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-551 (CCPA 1969)” (MPEP p 2100-8, c 2, I 45-48; p 2100-9, c 1, l 1-4). The Examiner has full latitude to interpret each claim in the broadest reasonable sense. The Examiner will reference prior art using terminology familiar to one of ordinary skill in the art. Such an approach is broad in concept and can be either explicit or implicit in meaning.
Response to Arguments
Applicant’s remarks/amendment was filed on 30 March 2026.
NPL “Oracle Database SQL Tuning Guide” by Ashdown et al. is newly introduced to address the latest claim amendment.
Applicant's arguments have been considered but they are moot in view of new ground(s) of rejection. However, the Examiner welcomes any suggestion(s) Applicant may have on moving prosecution forward.
Claim Rejections - 35 USC § 112
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 1-20 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.
Claim 1 recites “dynamically monitoring the database instance using metrics objects, wherein the metrics objects are generated at runtime of individual tasks based on the metrics definitions, generation, modification, or collection logic, and are generated in a namespace for a corresponding individual task that the metrics object is generated to track”.
It is not clear which of the metric objects is the metric object.
Claim 9 (a computer readable medium claim) corresponds in scope to Claim 1, and are similarly rejected.
Claim 17 (a system claim) corresponds in scope to Claim 1, and are similarly rejected.
Claims 2-8, 10-16 and 18-20 depend from claim 1, 9 and 17, and are rejected for the same reason(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph.
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.
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 37 CFR 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 1, 8-9 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2004/0073763 by Dageville et al. (“Dageville”) in view of NPL “Oracle Database SQL Tuning Guide” by Ashdown et al. (“Ashdown”).
As to Claim 1, Dageville teaches a computer-implemented method comprising: maintaining metric definitions (Dageville: at least ¶0042; “maintain, in statistics 160” and “maintenance of statistics 160”; ¶0018 also discloses “uses global internal value 14 to compute (see logic 15) another internal value 17 (also called "memory bound") which is used in allocation of memory for each operator”), metric generation logic (Dageville: at least ¶¶0008, 0018; “derives, from the externally-set global value an internal value (called "memory bound") that is used in allocating memory for the application (e.g. memory required by an operator that implements a database query)” and “compute (see logic 15) another internal value 17 (also called "memory bound") which is used in allocation of memory for each operator”; ¶0042 also discloses “statistics 160, the amount of memory (called "work area memory") 163 that is actually used by the operators”), metric modification logic (Dageville: at least ¶0040; “update statistics 160”), or metric collection logic (Dageville: at least ¶0042; “maintain, in statistics 160” and “maintenance of statistics 160”; ¶0018 also discloses “compute (see logic 15) another internal value 17 (also called "memory bound") which is used in allocation of memory for each operator”);
maintaining a database instance on a computing node (Dageville: at least ¶0018; “database system 10”);
dynamically monitoring the database instance using metrics objects (at least ¶0020; “if the externally-set global value is being exceeded by the total memory that is currently allocated by database system 10, the database system 10 reduces the memory bound (and vice versa), so that the total memory allocated by database system 10 approaches the externally-set global value 11, either as a target or as a limit” and “database system 10 periodically (e.g. once every 3 seconds) revises memory bound 17 based on statistics related to memory usage. Database system 10 may also revise memory bound 17 asynchronously, when allocating memory, e.g. if the total memory allocated by the database system 10 exceeds the externally-set global value 11 by a predetermined amount (which may be, e.g. zero, or 10% of the value 11)”; ¶0029 further discloses “value 11 is used as a target for the total memory to be allocated for internal use by processes (sometimes called "server processes") that execute the database queries”; ¶0042 further discloses “amount of memory (called "work area memory") 163 that is actually used by the operators”; ¶0062 further discloses “when the work area estimated by the sort operator exceeds a predetermined value (such as 128 KB), the sort operator registers its work area profile (including the estimate)”; note: monitoring memory usage of database instance), wherein the metrics objects are generated at runtime of individual tasks based on the metrics definitions, generation, modification, or collection logic (Dageville: at least ¶0007; “the computer allocates memory (e.g. to be used by a database query)”; ¶¶0029, 0031 further disclose “each query may be executed via one or more operators, such as sort, hash-join and bitmap merge, in the normal manner. During execution of each query, computer 100 allocates memory as described below” and “on completion of query processing, process 120A deallocates (see act 123) the previously allocated memory and also updates (see act 124) the memory usage statistics”; ¶0037 further discloses “determines the amount of memory to be allocated for a sort operator in a database application”); and
processing, based on hierarchical relationships between the metrics objects, at least one task of the one or more tasks upon closing of the at least one task (Dageville: at least ¶0070; “after completion of execution of a query, statistics specific to the query may be saved for use in making an estimate when that very same query needs to be executed again (e.g. by another process)”; ¶0062 also discloses “when the work area estimated by the sort operator exceeds a predetermined value (such as 128 KB), the sort operator registers its work area profile (including the estimate)”; ¶0023 also discloses “each query process uses the global internal value 14 to derive the amount of memory to be allocated for an operator”; ¶0032 further discloses “there are too many processes and that the total allocated memory may significantly exceed the externally-set global value 11, in which case memory broker 115 reduces either or both of internal values 14 and 17, so that lesser amount of memory (than the current amount) is allocated in the future by the processes”; Fig. 1A shows hierarchical relationships of 13, 14, 15, 17).
Dageville does not explicitly disclose, but Ashdown discloses wherein the metrics objects are generated in a namespace for a corresponding individual task that the metrics object is generated to track (Ashdown: at least 6.4.1; “the following output table shows the execution plan that the optimizer chose to execute the SQL statement in Example 6-3”; 7.2.1 on 7-4 further discloses “the following example shows that the optimizer has chosen a different plan, using a hash join. The Note section shows that the optimizer used statistics feedback to adjust its cost estimates for the second execution of the query, thus illustrating automatic reoptimization”; note: tracking of query task).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Ashdown’s feature of wherein the metrics objects are generated in a namespace for a corresponding individual task that the metrics object is generated to track (Ashdown: at least 6.4.1 & 7.2.1 on 7-4) with Dageville’s method.
The suggestion/motivation for doing so would have been to perform optimization and reoptimization of queries (Ashdown: at least 7.2.1 on 7-2 & 7-4; “adaptive optimizer” and adaptive optimization).
Claim 9 (a computer readable medium claim) corresponds in scope to Claim 1, and are similarly rejected.
Claim 17 (a system claim) corresponds in scope to Claim 1, and are similarly rejected.
As to Claim 8, Dageville and Ashdown teach the method of claim 1, wherein processing the at least one task of the one or more tasks upon the closing of the at least one task comprises applying a retention policy to the metrics object, and a retention policy specifies conditions for storage or removal from storage of a corresponding metrics object (Dageville: at least ¶0070; “after completion of execution of a query, statistics specific to the query may be saved for use in making an estimate when that very same query needs to be executed again (e.g. by another process)”; note: completion of execution as conditions for storage of metrics object).
Claim 16 (a computer readable medium claim) corresponds in scope to Claim 8, and are similarly rejected.
Claims 2, 10 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2004/0073763 by Dageville et al. (“Dageville”) in view of NPL “Oracle Database SQL Tuning Guide” by Ashdown et al. (“Ashdown”), and further in view of US PGPUB 2023/0004402 by Ankalikar et al. (“Ankalikar”).
As to Claim 2, Dageville and Ashdown teach the method of claim 1.
Dageville and Ashdown do not explicitly disclose, but Ankalikar discloses wherein the database instance comprises a consolidated database instance, the consolidated database instance is associated with one or more pluggable database instances, and the computing node is in a cluster of computing nodes (Ankalikar: at least ¶¶0021-0022; “one or more computing nodes that might each have one or more consolidated database (CDB) instances and one or more pluggable databases (PDBs) that may be open in the consolidated database instance at any given time” and “a cluster 100 that may include a computer device 101, computing nodes 110a-n, database 130, and a cluster manager 140. Each computing node 110a-n might comprise one or more consolidated database instances—such as consolidated databases 120a1-an as illustrated for computing node 110a—which might in turn have one or more pluggable databases (PDBs) open at any given time (see e.g., 125a11−1n)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Ankalikar’s feature of wherein the database instance comprises a consolidated database instance, the consolidated database instance is associated with one or more pluggable database instances, and the computing node is in a cluster of computing nodes (Ankalikar: at least ¶¶0021-0022) with the method disclosed by Dageville and Ashdown.
The suggestion/motivation for doing so would have been to “provide a method, apparatus, and product for scalable specification and self-governance for autonomous databases, cluster databases, and multi-tenant databases in cloud and on-prem environment” (Ankalikar: at least ¶0005).
Claim 10 (a computer readable medium claim) corresponds in scope to Claim 2, and are similarly rejected.
Claim 18 (a system claim) corresponds in scope to Claim 2, and are similarly rejected.
Claims 3, 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2004/0073763 by Dageville et al. (“Dageville”) in view of NPL “Oracle Database SQL Tuning Guide” by Ashdown et al. (“Ashdown”), and further in view of US PGPUB 2006/0140370 by Agarwal et al. (“Agarwal”).
As to Claim 3, Dageville and Ashdown teach the method of claim 1.
Dageville and Ashdown do not explicitly disclose, but Agarwal discloses wherein generating the metrics objects at the runtime of the individual tasks is further based on metrics object definition templates (Agarwal: at least ¶¶0028, 0030; “for example, consider process accounting records logged by Unix.TM. systems, which contain the consumption of various resources by a process” and “… corresponding metric definitions represented by MetricDefinition class”; ¶0024 further discloses “the BaseMetricDefinition class 36 defines the properties of a metric, such as its unit of measurement, data type, etc, and is therefore used to represent metrics such as CPU utilization, memory consumption and so on”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Agarwal’s feature of wherein generating the metrics objects at the runtime of the individual tasks is further based on metrics object definition templates (Agarwal: at least ¶¶0024, 0028, 0030) with the method disclosed by Dageville and Ashdown.
The suggestion/motivation for doing so would have been to provide a object-oriented BaseMetricDefinition class that encapsulates “properties of a metric, such as its unit of measurement, data type, etc.” used to represent metrics such as CPU utilization, memory consumption and so on” and that model actual values of metrics at different points of time using its instances (Agarwal: at least ¶¶0024-0025).
Claim 11 (a computer readable medium claim) corresponds in scope to Claim 3, and are similarly rejected.
Claim 19 (a system claim) corresponds in scope to Claim 3, and are similarly rejected.
Claims 4-5, 12-13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2004/0073763 by Dageville et al. (“Dageville”) in view of NPL “Oracle Database SQL Tuning Guide” by Ashdown et al. (“Ashdown”), and further in view of US PGPUB 2011/0016084 by Mundy et al. (“Mundy”).
As to Claim 4, Dageville and Ashdown teach the method of claim 1, wherein processing the at least one task of the one or more tasks upon the closing of the at least one task (Dageville: at least ¶0070; “after completion of execution of a query, statistics specific to the query may be saved for use in making an estimate when that very same query needs to be executed again (e.g. by another process)”).
Dageville and Ashdown do not explicitly disclose, but Mundy discloses rolling up metrics in the metrics object into another metrics object for a parent task (Mundy: at least ¶0017; “the summing or "rolling up" of subordinate costs for tasks, materials, etc., into their successively higher level "parent" tasks, materials, etc”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Mundy’ feature of rolling up metrics in the metrics object into another metrics object for a parent task (ndy: at least ¶0017) with method disclosed by Dageville and Ashdown.
The suggestion/motivation for doing so would have been to achieve “subdivision of effort required to achieve an objective” (Mundy: at least ¶¶0016-0017).
Claim 12 (a computer readable medium claim) corresponds in scope to Claim 4, and are similarly rejected.
Claim 20 (a system claim) corresponds in scope to Claim 4, and are similarly rejected.
As to Claim 5, Dageville, Ashdown and Mundy teach the method of claim 4, wherein rolling up metrics in the metrics object into another metrics object for a parent task comprises adding an individual metric to a matching parent metric (Mundy: at least ¶0017; “the summing or "rolling up" of subordinate costs for tasks, materials, etc., into their successively higher level "parent" tasks, materials, etc”).
Claim 13 (a computer readable medium claim) corresponds in scope to Claim 5, and are similarly rejected.
Claims 4-5, 7, 12-13, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2004/0073763 by Dageville et al. (“Dageville”) in view of NPL “Oracle Database SQL Tuning Guide” by Ashdown et al. (“Ashdown”), and further in view of US PGPUB 2011/0282864 by Collins et al. (“Collins”).
As to Claim 4, Dageville and Ashdown teach the method of claim 1, wherein processing the at least one task of the one or more tasks upon the closing of the at least one task (Dageville: at least ¶0070; “after completion of execution of a query, statistics specific to the query may be saved for use in making an estimate when that very same query needs to be executed again (e.g. by another process)”).
Dageville and Ashdown do not explicitly disclose, but Collins discloses rolling up metrics in the metrics object into another metrics object for a parent task (Collins: at least ¶¶0011, 0050; “the costs of the multiple subqueries may be added together in order to get a cost which may be compared against other optimizable filters in the same query”; claim 14 further discloses “the cost of the query formed with the clause combining the set of parallel subqueries being determined by calculating computational costs based on a selectivity of the filters for each of the subqueries”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Collins’ feature of rolling up metrics in the metrics object into another metrics object for a parent task (Collins: at least ¶¶0011, 0050, claim 14) with the method disclosed by Dageville and Ashdown.
The suggestion/motivation for doing so would have been to implement query optimization in a database system (Collins: at least ¶0011).
Claim 12 (a computer readable medium claim) corresponds in scope to Claim 4, and are similarly rejected.
Claim 20 (a system claim) corresponds in scope to Claim 4, and are similarly rejected.
As to Claim 5, Dageville, Ashdown and Collins teach the method of claim 4, wherein rolling up metrics in the metrics object into another metrics object for a parent task comprises adding an individual metric to a matching parent metric (Collins: at least ¶¶0011, 0050; “the costs of the multiple subqueries may be added together in order to get a cost which may be compared against other optimizable filters in the same query”; claim 14 further discloses “the cost of the query formed with the clause combining the set of parallel subqueries being determined by calculating computational costs based on a selectivity of the filters for each of the subqueries”).
Claim 13 (a computer readable medium claim) corresponds in scope to Claim 5, and are similarly rejected.
As to Claim 7, Dageville, Ashdown and Collins teach the method of claim 4, wherein child metrics objects are rolled up into parent metrics objects based on matching metric labels (Collins: at least ¶¶0011, 0050; “the costs of the multiple subqueries may be added together in order to get a cost which may be compared against other optimizable filters in the same query”; claim 14 further discloses “the cost of the query formed with the clause combining the set of parallel subqueries being determined by calculating computational costs based on a selectivity of the filters for each of the subqueries”).
Claim 15 (a computer readable medium claim) corresponds in scope to Claim 7, and are similarly rejected.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2004/0073763 by Dageville et al. (“Dageville”) in view of NPL “Oracle Database SQL Tuning Guide” by Ashdown et al. (“Ashdown”), and further in view of US PGPUB 2011/0282864 by Collins et al. (“Collins”), and further in view of US PGPUB 2014/0095540 by Hsiao et al. (“Hsiao”).
As to Claim 6, Dageville, Ashdown and Collins teach the method of claim 4.
Dageville, Ashdown and Collins do not explicitly disclose, but Hsiao discloses wherein a parent task comprises an immediate parent (Hsiao: at least ¶0069; “one or more continuous queries 150 that may contain subqueries 152, 154 (e.g., continuous and/or tactical subqueries). For example, a continuous query 150 (e.g., a query configured to be run against a stream or relation) may include one or more subqueries 152, 154 or nested subqueries 154 upon which the query sits (i.e., on which it depends). More specifically, a continuous query 150 may include a subquery 152 which may in turn include a subquery 154 (e.g., nested within the first subquery 152)”) or a rolling up metrics in the metrics object into another metrics object for a parent task comprises adding an individual metric to a matching parent metric.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Hsiao’s feature of wherein a parent task comprises an immediate parent (Hsiao: at least ¶0069) or a rolling up metrics in the metrics object into another metrics object for a parent task comprises adding an individual metric to a matching parent metric with the method disclosed by Dageville, Ashdown and Collins.
The suggestion/motivation for doing so would have been to provide techniques for “chaining continuous queries” (Hsiao: at least ¶0005) where “one or more continuous queries 150 that rely on one or more subqueries 152” (Hsiao: at least ¶0089).
Claim 14 (a computer readable medium claim) corresponds in scope to Claim 6, and are similarly rejected.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Huen Wong whose telephone number is (571) 270-3426. The examiner can normally be reached on Monday - Friday (10:30AM EST - 6:30PM EST). If attempts to reach the examiner by telephone are unsuccessful, the Examiner's supervisor, Charles Rones can be reached on (571) 272-4085. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300 for regular communications and after final communications.
Information regarding the status of an application may be obtained from thePatent 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.
/H .W./
Examiner, AU 2168
31 March 2026
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168