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.
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 07
July 2026 has been entered.
Response to Arguments
Applicant’s remarks/amendment was filed on 07 July 2026.
US 2017/0004173 by Simitsis 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.
Abstract
According to the MPEP, “the abstract should be in narrative form and generally limited to a single paragraph on a separate sheet preferably within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, "The disclosure concerns," "The disclosure defined by this invention," "The disclosure The following is a quotation of 35 U.S.C. 103 which form describes," etc. In addition, the form and legal phraseology often used in patent claims, such as "means" and "said," should be avoided."
The abstract of the disclosure is objected to because it includes “comprise” at page 1, line 3 of the disclosure. “Comprise” is a legal phraseology and should be changed/removed.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
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”), and further in view of US PGPUB 2017/0004173 by Simitsis et al. (“Simitsis”).
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 at least a subset of the metrics objects have a hierarchical relationship with a metrics object (Dageville: at least Fig. 1A shows hierarchical relationships of 13, 14, 15, 17); and
processing, based on the 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 the metrics objects are generated in a namespace for a corresponding individual task that an individual metrics object is generated to track (Ashdown: at least 6.4.1; “the following output table shows t8he 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), different tasks are in different namespaces (Ashdown: at least 21.3; “Oracle recommends the following naming convention: component_name.subcomponent_name.operation name. For operations inside the database, Oracle recommends using ORA for the component name. For example, a materialized view refresh could be named ORA.MV.refresh. An E-Business Suite payroll function could be named EBIZ.payroll”; note: ORA.MV.refresh and EBIZ.payroll as examples of tasks in different namespaces).
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 the metrics objects are generated in a namespace for a corresponding individual task that an individual metrics object is generated to track (Ashdown: at least 6.4.1 & 7.2.1 on 7-4), different tasks are in different namespaces (Ashdown: at least 21.3) 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).
Dageville and Ashdown do not explicitly disclose, but Simitsis discloses at least a subset of the metrics objects have a hierarchical relationship with a metrics object for a corresponding parent task (Simitsis: at least ¶0019; “query tree can be rendered as described with respect to FIG. 6A below. In the graphical representations, associated performance metrics are displayed within each of the operator nodes”; ¶¶0050, 0054, 0056, 0058 further disclose “query tree is displayed with the performance metrics in a user interface with navigation controls” and “root node is a join operator 610 that is shown to be waiting on its descendant nodes 612 and 622” and “join node 622 is shown to be finished and its descendant nodes include select node 624 and scan node 634” and “the “Log Scaled Metrics” option allows the user to change the scale of the performance metrics display in the query tree 601”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Simitsis’ feature of at least a subset of the metrics objects have a hierarchical relationship with a metrics object for a corresponding parent task (Simitsis: at least ¶¶0019, 0050, 0054, 0056, 0058) with the method disclosed by Dageville and Ashdown.
The suggestion/motivation for doing so would have been to “provide users with real-time metrics and analysis during the execution of a query” (Simitsis: at least ¶0010) and display associated performance metrics “within each of the operator nodes, allowing the user to view the performance metrics associated with each of the operators in real-time” (Simitsis: at least ¶0019).
Claim 9 (a computer readable medium claim) corresponds in scope to Claim 1 and is similarly rejected.
Claim 17 (a system claim) corresponds in scope to Claim 1 and is similarly rejected.
As to Claim 8, Dageville, Ashdown and Simitsis 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 is 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 2017/0004173 by Simitsis et al. (“Simitsis”), and further in view of US PGPUB 2023/0004402 by Ankalikar et al. (“Ankalikar”).
As to Claim 2, Dageville, Ashdown and Simitsis teach the method of claim 1.
Dageville, Ashdown and Simitsis 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, Ashdown and Simitsis.
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 is similarly rejected.
Claim 18 (a system claim) corresponds in scope to Claim 2 and is 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 2017/0004173 by Simitsis et al. (“Simitsis”), and further in view of US PGPUB 2006/0140370 by Agarwal et al. (“Agarwal”).
As to Claim 3, Dageville, Ashdown and Simitsis teach the method of claim 1.
Dageville, Ashdown and Simitsis 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, Ashdown and Simitsis.
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 is similarly rejected.
Claim 19 (a system claim) corresponds in scope to Claim 3 and is similarly rejected.
Claims 4-6, 12-14 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 2017/0004173 by Simitsis et al. (“Simitsis”), and further in view of US PGPUB 2011/0016084 by Mundy et al. (“Mundy”).
As to Claim 4, Dageville, Ashdown and Simitsis 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, Ashdown and Simitsis 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, Ashdown and Simitsis.
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 is similarly rejected.
Claim 20 (a system claim) corresponds in scope to Claim 4 and is similarly rejected.
As to Claim 5, Dageville, Ashdown, Simitsis 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 is similarly rejected.
As to Claim 6, Dageville, Ashdown, Simitsis and Mundy teach the method of claim 4, wherein a parent task comprises an immediate parent (Simitsis: at least ¶0019; “query tree can be rendered as described with respect to FIG. 6A below. In the graphical representations, associated performance metrics are displayed within each of the operator nodes”; ¶¶0050, 0054, 0056, 0058 further disclose “query tree is displayed with the performance metrics in a user interface with navigation controls” and “root node is a join operator 610 that is shown to be waiting on its descendant nodes 612 and 622” and “join node 622 is shown to be finished and its descendant nodes include select node 624 and scan node 634” and “the “Log Scaled Metrics” option allows the user to change the scale of the performance metrics display in the query tree 601”) 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.
Claim 14 (a computer readable medium claim) corresponds in scope to Claim 6 and is similarly rejected.
Claims 4-7, 12-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 2017/0004173 by Simitsis et al. (“Simitsis”), and further in view of US PGPUB 2011/0282864 by Collins et al. (“Collins”).
As to Claim 4, Dageville, Ashdown and Simitsis 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, Ashdown and Simitsis 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, Ashdown and Simitsis.
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 is similarly rejected.
Claim 20 (a system claim) corresponds in scope to Claim 4 and is similarly rejected.
As to Claim 5, Dageville, Ashdown, Simitsis 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 is similarly rejected.
As to Claim 6, Dageville, Ashdown, Simitsis and Collins teach the method of claim 4, wherein a parent task comprises an immediate parent (Simitsis: at least ¶0019; “query tree can be rendered as described with respect to FIG. 6A below. In the graphical representations, associated performance metrics are displayed within each of the operator nodes”; ¶¶0050, 0054, 0056, 0058 further disclose “query tree is displayed with the performance metrics in a user interface with navigation controls” and “root node is a join operator 610 that is shown to be waiting on its descendant nodes 612 and 622” and “join node 622 is shown to be finished and its descendant nodes include select node 624 and scan node 634” and “the “Log Scaled Metrics” option allows the user to change the scale of the performance metrics display in the query tree 601”) 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.
Claim 14 (a computer readable medium claim) corresponds in scope to Claim 6 and is similarly rejected.
As to Claim 7, Dageville, Ashdown, Simitsis 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 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 is similarly rejected.
Relevant Prior Art
US 2007/0240165 by Carey et al. discloses “in response to the query from the respective namespace 16a, 16b, 16c, each of the data sources 12a, 12b, 12c, provides data stored therein regarding the specified hardware element, e.g., CPU1, as represented by arrows 50a, 50b, 50c, and 52a, 52b, 52c” (Carey: at least ¶0015).
Conclusion
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
15 July 2026
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168
Prosecution Insights