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 .
This communication is in response to Amendment filed on July 10, 2026.
Claims 1-20 are pending. Claims 1, 8 and 14 are amended.
Response to Arguments
Referring to the 35 USC 101 rejection of claims 1-20, Applicant’s arguments have been considered but are not persuasive.
Applicant argues that the claims as amended do not recite mental steps. However, Examiner respectfully disagrees. The added limitation of ‘determining whether upgrading the version of the database platform depends on a resource’ is a mental step. A user can mentally make this determination.
Furthermore, the addition of the limitations ‘wherein the first step comprises upgrading a version of a database platform associated with the database” and “in response to determining that the database platform depends on the resource, installing the resource prior to implementing the first step” are considered using of a computer or other machinery in its ordinary capacity for tasks such as storing or simply adding computer components after the fact to an abstract idea (mental process) and does not integrate a judicial exception into a practical application or provide significantly more.
As such, Examiner maintains the 101 rejection of the claims.
Applicant’s arguments with respect to claims 1-20 have been considered but are moot in view of the new grounds of rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 and 14 recite:
obtaining user input corresponding to a target database state for the database; generating, based on the user input, a target state configuration for the database; determining a current state configuration for the database;
generating a set of steps to change the configuration of the database from the current state configuration to the target state configuration; and
implementing the set of steps based on a healthiness state of the database, thereby configuring the database according to the target state configuration; wherein the implementing of the set of steps based on a healthiness state of the database includes at least:
determining whether the healthiness state of the database indicates a healthy state;
in response to determining that the healthiness state of the database indicates an unhealthy state, implementing an error handling to the database for a first step in the set of steps, wherein the first step comprises upgrading a version of a database platform associated with the database, wherein the implementing an error handling comprises:
determining whether upgrading the version of the database platform depends on a resource; and
in response to determining that the database platform depends on the resource, installing the resource prior to implementing the first step;
implementing the first step the set of steps;
determining whether the first step is successful; and
in response to determining that the first step is unsuccessful, implementing a remedial step;
wherein the method is performed using one or more processors.
Step 1: The claims as a whole fall within one or more statutory categories.
Step 2A prong 1: At least claims 1 and 14 recite limitations that are abstract ideas.
The limitations “generating, based on the user input, a target state configuration for the database”, “determining a current state configuration for the database” and “generating a set of steps to change the configuration of the database from the current state configuration to the target state configuration” are mental steps. A user can mentally generate a desired state configuration for a database based on the user goal for the target database state, determine the current state of the database and mentally generate steps to achieve the change in state configuration Thus, the claimed limitations can be performed by the human mind.
The limitations of “implementing the set of steps based on a healthiness state of the database, thereby configuring the database according to the target state configuration” and “wherein the implementing of the set of steps based on a healthiness state of the database includes at least: determining whether the healthiness state of the database indicates a healthy state; in response to determining that the healthiness state of the database indicates an unhealthy state, implementing an error handling to the database for a first step in the set of steps, wherein the implementing an error handling comprises: determining whether upgrading the version of the database platform depends on a resource” and “implementing the first step the set of steps” are also mental steps. A user can implement steps to change a configuration of the database to an intended target state based on a user determined healthiness state of the database and use the computer to perform the steps to achieve that state. Thus, the claimed limitations can be performed by the human mind. The implementing of error handling to the database is a mental step that can be achieved in the human mind, where the user can mentally implement the error handling steps. Thus, the claimed limitations can be performed by the human mind.
The limitations of “determining whether the first step is successful; and in response to determining that the first step is unsuccessful, implementing a remedial step” are also mental steps. Similarly, the determination as to whether a first step is successful or unsuccessful can be done by a user mentally. The implementing of a remedial step to the database is also a mental step that can be achieved in the human mind, where the user can mentally perform steps using the computer to remedy an error. Thus, the claimed limitations can be performed by the human mind.
Step 2A prong 2: Claims 1 and 14 recite the limitation “obtaining user input corresponding to a target database state for the database”. This limitation is an additional element and is insignificant extra-solution activity as receiving of user input data (i.e. mere data gathering) such as 'obtaining information' as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
Claims 1 and 14 recite the limitations “wherein the first step comprises upgrading a version of a database platform associated with the database” and “in response to determining that the database platform depends on the resource, installing the resource prior to implementing the first step”. This limitation is an additional element and is using of a computer or other machinery in its ordinary capacity for tasks such as storing or simply adding computer components after the fact to an abstract idea (mental process) does not integrate a judicial exception into a practical application or provide significantly more.
Furthermore, Claims 1 and 14 recite the following additional elements “one or more processors”, “one or more memories”, “a system”, and “a database”, note that these recited additional elements are a high-level recitation of generic computer components or software to perform the mental process and applied on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
Step 2B: The conclusions for the additional elements representing mere implementation using a computer and computer software are carried over and do not provide significantly more.
With respect to the "obtaining” limitation is identified as insignificant extra-solution activity above when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and thus remains insignificant extra-solution activity that does not provide significantly more.
Furthermore, the “upgrading” and “installing” limitations identified as insignificant extra-solution activity above when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), “iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93” and thus remains insignificant extra-solution activity that does not provide significantly more.
Therefore, the claims 1 and 14 as a whole do not change this conclusion and the claims are ineligible.
Claim 8 recites:
obtaining a target database state for the database that includes a general configuration indication;
generating a target state configuration for the database based on a pre-defined configuration that corresponds to the general configuration indication;
determining a current state configuration for the database;
generating a set of steps to change the configuration of the database from the current state configuration to the target state configuration; and
implementing the set of steps based on a healthiness state of the database, thereby configuring the database according to the target state configuration; wherein the implementing of the set of steps based on a healthiness state of the database includes at least:
determining whether the healthiness state of the database indicates a healthy state;
in response to determining that the healthiness state of the database indicates an unhealthy state, implementing an error handling to the database for a first step in the set of steps wherein the first step comprises upgrading a version of a database platform associated with the database, wherein the implementing an error handling comprises:
determining whether upgrading the version of the database platform depends on a resource; and
in response to determining that the database platform depends on the resource, installing the resource prior to implementing the first step;
implementing the first step the set of steps;
determining whether the first step is successful; and
in response to determining that the first step is unsuccessful, implementing a remedial step;
wherein the method is performed using one or more processors.
Step 1: The claim as a whole falls within one or more statutory categories.
Step 2A prong 1: At least claim 8 recites limitations that are abstract ideas.
The limitations “generating a target state configuration for the database based on a pre-defined configuration that corresponds to the general configuration indication”, “determining a current state configuration for the database” and “generating a set of steps to change the configuration of the database from the current state configuration to the target state configuration” are mental steps. A user can mentally generate a desired state configuration for a database based on the user goal for the target database state, determine the current state of the database and mentally generate steps to achieve the change in state configuration Thus, the claimed limitations can be performed by the human mind.
The limitations of “implementing the set of steps based on a healthiness state of the database, thereby configuring the database according to the target state configuration” and “wherein the implementing of the set of steps based on a healthiness state of the database includes at least: determining whether the healthiness state of the database indicates a healthy state; in response to determining that the healthiness state of the database indicates an unhealthy state, implementing an error handling to the database for a first step in the set of steps, wherein the first step comprises upgrading a version of a database platform associated with the database, wherein the implementing an error handling comprises: determining whether upgrading the version of the database platform depends on a resource” and “implementing the first step the set of steps” are also mental steps. A user can implement steps to change a configuration of the database to an intended target state based on a user determined healthiness state of the database and use the computer to perform the steps to achieve that state. Thus, the claimed limitations can be performed by the human mind. The implementing of error handling to the database is a mental step that can be achieved in the human mind, where the user can mentally implement the error handling steps. Thus, the claimed limitations can be performed by the human mind.
The limitations of “determining whether the first step is successful; and in response to determining that the first step is unsuccessful, implementing a remedial step” are also mental steps. Similarly, the determination as to whether a first step is successful or unsuccessful can be done by a user mentally. The implementing of a remedial step to the database is also a mental step that can be achieved in the human mind, where the user can mentally perform steps using the computer to remedy an error. Thus, the claimed limitations can be performed by the human mind.
Step 2A prong 2: Claim 8 recites the limitation “obtaining a target database state for the database that includes a general configuration indication”. This limitation is an additional element and is insignificant extra-solution activity as receiving a target database state data as input for analysis (i.e. mere data gathering) such as 'obtaining information' as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
Claim 8 recites the limitation “in response to determining that the database platform depends on the resource, installing the resource prior to implementing the first step”. This limitation is an additional element and is using of a computer or other machinery in its ordinary capacity for tasks such as storing or simply adding computer components after the fact to an abstract idea (mental process) does not integrate a judicial exception into a practical application or provide significantly more.
Furthermore, Claim 8 recites the following additional elements “one or more processors” and “a database”, note that these recited additional elements are a high-level recitation of generic computer components or software to perform the mental process and applied on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
Step 2B: The conclusions for the additional elements representing mere implementation using computer components and software are carried over and do not provide significantly more.
With respect to the "obtaining” limitation is identified as insignificant extra-solution activity above when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and thus remains insignificant extra-solution activity that does not provide significantly more.
Furthermore, the “installing” limitation identified as insignificant extra-solution activity above when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), “iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93” and thus remains insignificant extra-solution activity that does not provide significantly more.
Therefore, the claim 8 as a whole does not change this conclusion and the claim is ineligible.
Claims 2, 3, 9, 15 and 16 depend from claims 1, 8 and 14 and thus include all the limitations of claims 1, 8 and 14, therefore claims 2, 3, 9, 15 and 16 recite the same abstract idea of "mental process".
Claims 2, 3, 9, 15 and 16 recite: (Claims 2,15) wherein the obtaining user input comprises receiving, from the user, natural language input corresponding to the target database state; (Claims 3, 16) wherein the obtaining user input further comprises prompting the user for additional natural language input corresponding to the target database state; (claim 9) wherein the obtaining user input comprises receiving, from the user, natural language input corresponding to the target database state; wherein the obtaining user input further comprises prompting the user for additional natural language input corresponding to the target database state.
Step 1: Claims 2, 3, 9, 15 and 16 as a whole fall within one or more statutory categories.
Step 2A prong 1: Claims 2, 3, 9, 15 and 16 depending from claims 1, 8 and 14 also recite mental concepts.
Step 2A prong 2: Claims 2, 3, 9, 15 and 16 furthermore recite: (Claims 2,15) wherein the obtaining user input comprises receiving, from the user, natural language input corresponding to the target database state; (Claims 3, 16) wherein the obtaining user input further comprises prompting the user for additional natural language input corresponding to the target database state; (claim 9) wherein the obtaining user input comprises receiving, from the user, natural language input corresponding to the target database state; wherein the obtaining user input further comprises prompting the user for additional natural language input corresponding to the target database state.
These limitations are additional elements and are insignificant extra-solution activity as receiving a target database state data as input for analysis (i.e. mere data gathering) such as 'obtaining information' as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
Step 2B:
With respect to the "receiving” and “prompting” limitations identified as insignificant extra-solution activity above when re-evaluated these elements are well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and thus remains insignificant extra-solution activity that does not provide significantly more.
Therefore, the claims 2, 3, 9, 15 and 16 as a whole do not change this conclusion and the claims are ineligible.
Claims 4-7, 10-13 and 17-20 depend from claims 1, 8 and 14 and thus include all the limitations of claims 1, 8 and 14, therefore claims 4-7, 10-13 and 17-20 recite the same abstract idea of "mental process".
Claims 4-7, 10-13 and 17-20 recite:
(Claims 4,17) wherein the generating the target state configuration for the database comprises processing the natural language input using a large language model (LLM); (Claims 5, 10, 18) wherein the generating a set of steps comprises evaluating the current state configuration and the target state configuration according to a set of rules to generate the set of steps;
(Claims 6,11,19) wherein the generating a set of steps comprises processing the current state configuration and the target state configuration using a machine learning model to generate the set of steps;
(Claims 7,20) wherein the generating, based on the user input, a target state configuration comprises identifying a pre-defined configuration that corresponds to a general configuration indication of the obtained user input;
(Claim 12) wherein the set of steps is generated based on a mapping between the current state configuration to the target state configuration;
(Claim 13) evaluating the database to verify that the target state configuration has been achieved.
Step 1: The claims as a whole fall within one or more statutory categories.
Step 2A prong 1: At least claims 4-7, 10-13 and 17-20 recite limitations that are abstract ideas.
The limitations “wherein the generating the target state configuration for the database comprises processing the natural language input” and “wherein the generating, based on the user input, a target state configuration comprises identifying a pre-defined configuration that corresponds to a general configuration indication of the obtained user input” are mental steps. A user can mentally process natural language input and mentally identify a pre-defined configuration corresponding to the user input. Thus, the claimed limitations can be performed by the human mind.
The limitations “wherein the generating a set of steps comprises evaluating the current state configuration and the target state configuration according to a set of rules to generate the set of steps” and “wherein the generating a set of steps comprises processing the current state configuration and the target state configuration” and “wherein the set of steps is generated based on a mapping between the current state configuration to the target state configuration” are mental steps. A user can mentally perform evaluation of configuration data according to a set of rules, mentally process the current and target state configuration data, and mentally generate steps based on a mapping between configuration states. Thus, the claimed limitations can be performed by the human mind.
The limitation “evaluating the database to verify that the target state configuration has been achieved” is a mental step. A user can mentally perform evaluation of the database to verify that a desired target state configuration has been achieved. Thus, the claimed limitation can be performed by the human mind.
Step 2A prong 2:
Furthermore, Claims 4, 6, 11, 17 and 19 recites the following additional elements “a large language model (LLM)” and “a machine learning model”, note that these recited additional elements are a high-level recitation of generic computer software to perform the mental processes and applied on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
Step 2B: The conclusions for the additional elements representing mere implementation using computer software are carried over and do not provide significantly more.
Therefore, the claims 4-7, 10-13 and 17-20 as a whole do not change this conclusion and the claims are ineligible.
To expedite a complete examination of the instant application, the claims
rejected under 35 U.S.C. 101 (nonstatutory) above are further rejected as set forth
below in anticipation of applicant amending these claims to place them within the four statutory categories of the invention.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries 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 nonobviousness.
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, 5, 7, 8, 10, 12-14, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2017/0169059 by Horowitz et al (hereafter Horowitz), in view of US Patent 8,949,305 issued to White, and further in view of US 2014/0173135 by Varney et al (hereafter Varney).
Referring to claim 1, Horowitz discloses a method for managing a configuration of a database [Abstract, para 11], the method comprising:
obtaining user input corresponding to a target database state for the database [user input to define goal states, para 168, Fig 7-9; para 41];
generating, based on the user input, a target state configuration for the database [definition of goal state accessed, para 15; instructions defining goal state are received, para 44, Fig 2, element 202];
determining a current state configuration for the database [current state of system e.g. database node is determined, para 41, 44, Fig 2, element 204; Fig 5, element 502];
generating a set of steps to change the configuration of the database from the current state configuration to the target state configuration [execution plan is created based on current state and defined goal state, to take a respective database node from the current state to the goal state, para 41; para 44, Fig 2, element 206; Fig 5, element 512]; and
implementing the set of steps based on a healthiness state of the database, thereby configuring the database according to the target state configuration [execution of transition to different states, para 41; each step of execution plan is executed on respective node and conducted as a cycle through flow 200, para 44; execution plan steps are executed to achieve the goal state, para 44-45; in response to determination if the database and respective nodes are in a valid state (para 64, Fig 5, element 506), and if a valid state is found 506, process 500 continues with generation of the execution plan at 512, para 66, Fig 5, element 512; execution of each step of the execution plan, para 70, Fig. 6, element 602],
wherein the implementing of the set of steps based on a healthiness state of the database includes at least:
determining whether the healthiness state of the database indicates a healthy state [determination as to if the database and respective nodes are in a valid state, para 64, Fig 5, element 506];
in response to determining that the healthiness state of the database indicates an unhealthy state, implementing reporting of error conditions for a first step in the set of steps wherein the first step comprises upgrading a version of a database platform associated with the database [in response to the valid state testing not passing 506, reporting at 510 on the condition or conditions that caused the issue is performed, para 64, Fig 5, element 510; wherein the current state evaluated indicates that software versions of the database processes on respective nodes, are too old to upgrade can be identified as an invalid state, or based on an exclusion rule identifying software too old to integrate with automation, para 64];
implementing the first step in the set of steps [wherein each step of the execution plan is executed, para 44; para 70, Fig 6, element 602];
determining whether the first step in the set of steps is successful [validation of proper execution of the operations of the step executed is performed by testing post-conditions of the operations for the step, para 45, 70, Fig 6, element 612]; and
in response to determining that the first step is unsuccessful, implementing a remedial step [in response to evaluation of an unexpected state e.g. error occurring in execution, triggering generation of a new execution plan to achieve the goal state and to compensate for any errors, para 45, 70, Fig 6, element 608];
wherein the method is performed using one or more processors [processor 1010, para 173, Fig 10].
While Horowitz discloses all of the above claimed subject matter and also discloses implementing reporting of error conditions in response to the invalid state of the database [in response to the valid state testing not passing 506, reporting at 510 on the condition or conditions that caused the issue is performed, para 64, Fig 5, element 510], it remains silent as to specifically implementing an error handling to the database in response to the error condition/invalid state; determining whether upgrading the version of the database platform depends on a resource; and in response to determining that the database platform depends on the resource, installing the resource prior to implementing the integrating the update.
White discloses identifying a non-responsive node/resource (Fig 2, step 231) [col. 20, lines 3-9] and recovering the non-responsive node with all queued configuration changes (Fig 2, step 243) [col. 20, lines 59-67].
Horowitz and White are analogous art because they are directed to the same field of endeavor- management of database configurations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the process of handling error conditions in Horowitz to include performing the recovery of a determined non-responsive node with all queued configuration changes, as taught by White, because it would achieve predictable results.
The ordinary skilled artisan would have been motivated to make this modification because the performing of a recovery of a non-responsive node in White refines the handling procedure of error conditions in Horowitz.
Still referring to claims 1 and 14, while Horowitz/White discloses all of the above claimed subject matter and also discloses implementing reporting of error conditions in response to the invalid state of the database [in response to the valid state testing not passing 506, reporting at 510 on the condition or conditions that caused the issue is performed, para 64, Fig 5, element 510] and receiving and updating database software versions [Horwitz, para 45, 68], it remains silent as to determining whether upgrading the version of the database platform depends on a resource; and in response to determining that the database platform depends on the resource, installing the resource prior to implementing the integrating the update.
Varney discloses that when a machine learns that it needs to run a different version of CDN software it issues a stop command to the services that need to be stopped (at least the service being updated, possibly others), it installs the proper version of the RPMs needed, and then restarts the required services [para 1574], wherein RPMs are new up to date system /application software packages [para 1614].
Horowitz, White and Varney are analogous art because they are directed to the same field of endeavor- management of database configurations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the process of handling error conditions with respect to new software updates in Horowitz with the detecting whether a proper version of the RPM system /application software packages is needed before installing it and before running a different version of CDN software, as taught by Varney, because it would achieve predictable results.
The ordinary skilled artisan would have been motivated to make this modification because the detection of whether a proper version of the RPM system /application software packages is needed before installing it and before running a different version of CDN software, as taught by Varney provides an extra layer of security to the error handling in Horowitz.
Referring to claim 14, the limitations of the claim are similar to those of claim 1 in the form of a system [Horowitz, system 1002, Fig 10] comprising one or more memories [Horowitz, memory devices 1012, Fig 10] and one or more processors [Horowitz, processor 1010, para 173, Fig 10]. As such, claim 14 is rejected for the same reasons as claim 1 above.
Referring to claim 8, Horowitz discloses a method for managing a configuration of a database [Horowitz, Abstract, para 11], the method comprising:
obtaining a target database state for the database that includes a general configuration indication [user input to define goal states, para 168, Fig 7-9; para 41];
generating a target state configuration for the database based on a pre-defined configuration that corresponds to the general configuration indication [wherein definition of goal state accessed, para 15; instructions defining goal state are received, para 44, Fig 2, element 202; state definitions are predefined, para 4, 16];
determining a current state configuration for the database [current state of system e.g. database node is determined, para 41, 44, Fig 2, element 204; Fig 5, element 502];
generating a set of steps to change the configuration of the database from the current state configuration to the target state configuration [execution plan is created based on current state and defined goal state, to take a respective database node from the current state to the goal state, para 41; para 44, Fig 2, element 206; Fig 5, element 512]; and
implementing the set of steps based on a healthiness state of the database, thereby configuring the database according to the target state configuration [execution of transition to different states, para 41; each step of execution plan is executed on respective node and conducted as a cycle through flow 200, para 44; execution plan steps are executed to achieve the goal state, para 44-45; in response to determination if the database and respective nodes are in a valid state (para 64, Fig 5, element 506), and if a valid state is found 506, process 500 continues with generation of the execution plan at 512, para 66, Fig 5, element 512; execution of each step of the execution plan, para 70, Fig. 6, element 602];
wherein the implementing of the set of steps based on a healthiness state of the database includes at least:
determining whether the healthiness state of the database indicates a healthy state [determination as to if the database and respective nodes are in a valid state, para 64, Fig 5, element 506];
in response to determining that the healthiness state of the database indicates an unhealthy state, implementing reporting of error conditions for a first step in the set of steps wherein the first step comprises upgrading a version of a database platform associated with the database [in response to the valid state testing not passing 506, reporting at 510 on the condition or conditions that caused the issue is performed, para 64, Fig 5, element 510; wherein the current state evaluated indicates that software versions of the database processes on respective nodes, are too old to upgrade can be identified as an invalid state, or based on an exclusion rule identifying software too old to integrate with automation, para 64];
implementing the first step in the set of steps [wherein each step of the execution plan is executed, para 44; para 70, Fig 6, element 602];
determining whether the first step in the set of steps is successful [validation of proper execution of the operations of the step executed is performed by testing post-conditions of the operations for the step, para 45, 70, Fig 6, element 612]; and
in response to determining that the first step is unsuccessful, implementing a remedial step [in response to evaluation of an unexpected state e.g. error occurring in execution, triggering generation of a new execution plan to achieve the goal state and to compensate for any errors, para 45, 70, Fig 6, element 608];
wherein the method is performed using one or more processors [processor 1010, para 173, Fig 10].
While Horowitz discloses all of the above claimed subject matter and also discloses implementing reporting of error conditions in response to the invalid state of the database [in response to the valid state testing not passing 506, reporting at 510 on the condition or conditions that caused the issue is performed, para 64, Fig 5, element 510], it remains silent as to specifically implementing an error handling to the database in response to the error condition/invalid state; determining whether upgrading the version of the database platform depends on a resource; and in response to determining that the database platform depends on the resource, installing the resource prior to implementing the integrating the update.
White discloses identifying a non-responsive node/resource (Fig 2, step 231) [col. 20, lines 3-9] and recovering the non-responsive node with all queued configuration changes (Fig 2, step 243) [col. 20, lines 59-67].
Horowitz and White are analogous art because they are directed to the same field of endeavor- management of database configurations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the process of handling error conditions in Horowitz to include performing the recovery of a determined non-responsive node with all queued configuration changes, as taught by White, because it would achieve predictable results.
The ordinary skilled artisan would have been motivated to make this modification because the performing of a recovery of a non-responsive node in White refines the handling procedure of error conditions in Horowitz.
Still referring to claim 8, while Horowitz/White discloses all of the above claimed subject matter and also discloses implementing reporting of error conditions in response to the invalid state of the database [in response to the valid state testing not passing 506, reporting at 510 on the condition or conditions that caused the issue is performed, para 64, Fig 5, element 510] and receiving and updating database software versions [Horwitz, para 45, 68], it remains silent as to determining whether upgrading the version of the database platform depends on a resource; and in response to determining that the database platform depends on the resource, installing the resource prior to implementing the integrating the update.
Varney discloses that when a machine learns that it needs to run a different version of CDN software it issues a stop command to the services that need to be stopped (at least the service being updated, possibly others), it installs the proper version of the RPMs needed, and then restarts the required services [para 1574], wherein RPMs are new up to date system /application software packages [para 1614].
Horowitz, White and Varney are analogous art because they are directed to the same field of endeavor- management of database configurations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the process of handling error conditions with respect to new software updates in Horowitz with the detecting whether a proper version of the RPM system /application software packages is needed before installing it and before running a different version of CDN software, as taught by Varney, because it would achieve predictable results.
The ordinary skilled artisan would have been motivated to make this modification because the detection of whether a proper version of the RPM system /application software packages is needed before installing it and before running a different version of CDN software, as taught by Varney provides an extra layer of security to the error handling in Horowitz.
Referring to claims 5, 10 and 18, Horowitz/White/Varney discloses that the generating a set of steps comprises evaluating the current state configuration and the target state configuration according to a set of rules to generate the set of steps [Horowitz, determining execution plan to transition from current state to a goal state includes intermediate states, where each state provides an additional feature or modification of one or more configurations that enable further transitions to the goal state, para 32].
Referring to claims 7 and 20, Horowitz/White/Varney discloses that the generating, based on the user input, a target state configuration comprises identifying a pre-defined configuration that corresponds to a general configuration indication of the obtained user input [Horowitz, wherein definition of goal state accessed, para 15; instructions defining goal state are received, para 44, Fig 2, element 202; state definitions are predefined, para 4, 16].
Referring to claim 12, Horowitz/White/Varney discloses that the set of steps is generated based on a mapping between the current state configuration to the target state configuration [Horowitz, database of predefined database states are searched for execution plan between current state and goal state, para 60].
Referring to claim 13, Horowitz/White/Varney discloses evaluating the database to verify that the target state configuration has been achieved [Horowitz, each transition from a first state to a second is tested and validated along a path to an ultimate goal state, para 5].
Claims 2-4, 9 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Horowitz, in view of White, in view of Varney, as applied to claims 1, 8 and 14 above, and further in view of US 2024/017321 by Shapiro et al (hereafter Shapiro).
Referring to claims 2 and 15, while Horowitz/White/Varney discloses all of the above claimed subject matter and also discloses receiving user input corresponding to goal states [Horowitz, para 18, Fig 7-9], it remains silent as to the user input specifically being natural language input. Shapiro discloses receiving natural language descriptions of a desired fabrication result as user input as a query request [Fig 5, element 502, para 194].
Horowitz, White, Varney and Shapiro are analogous art because they are directed to the same field of endeavor- processing of requests for information from a system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the goal state input by a user in Horowitz to include a natural language description format because it would achieve predictable results and would require mere substitution of query input formatting.
The ordinary skilled artisan would have been motivated to make this modification because the natural language description format of the user query input in Shapiro further defines the formatting of the goal state input by the user in Horowitz.
Referring to claims 3 and 16, Horowitz/White/Varney/Shapiro discloses that the obtaining user input further comprises prompting the user for additional natural language input corresponding to the target database state [Shapiro, rendering parameters added to natural language description, para 106, 164-165].
Referring to claims 4 and 17, Horowitz/White/Varney/Shapiro discloses that the generating the target state configuration for the database comprises processing the natural language input using a large language model (LLM) [Shapiro, LLM uses natural language description input to generate rendering instructions, para 82].
Claim 9 is a combination of claims 2 and 3 and as such is rejected for the same reasons as the latter claims.
Claims 6, 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Horowitz, in view of White, in view of Varney, as applied to claims 1, 8 and 14 above, and further in view of US 2020/0151609 by Ambardekar et al (hereafter Ambardekar).
Referring to claims 6, 11 and 19, while Horowitz/White discloses all of the above claimed subject matter and also discloses processing the current state configuration and the target state configuration to generate the set of steps [Horowitz, execution plan is created based on current state and defined goal state, to take a respective database node from the current state to the goal state, para 41; para 44, Fig 2, element 206; Fig 5, element 512], it remains silent as to the processing of the current state configuration and the target state configuration being done using a machine learning model.
Ambardekar discloses using collected system state data to train a regression machine learning algorithm to predict whether indented or desired system states will result in system overload and depending on the prediction, steps are taken to efficiently change system state [Abstract; para 3].
Horowitz, White, Varney and Ambardekar are analogous art because they are directed to the same field of endeavor- processing of input state information. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the generation of the execution plan based on input current state and desired predefined state information to arrive at a desired goal state, as taught by Horowitz to include the training of a regression machine learning model to predict a target outcome (i.e. processor overload) as taught by Ambardekar because it would achieve predictable results.
The ordinary skilled artisan would have been motivated to make this modification because the use of the trained regression machine learning model of Ambardekar to predict a certain outcome (processor load) provides a further layer of control in the configuration of the execution plan to achieve a certain goal state as taught by Horowitz.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Hung et al (US 2019/0102411) directed to: rule based autonomous database cloud service framework that recites database configurations and error handling [entire document].
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 CHERYL M SHECHTMAN whose telephone number is (571)272-4018. The examiner can normally be reached on Mon-Fri: 8am-4pm.
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, Amy Ng can be reached on 571-270-1698. 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.
CHERYL M SHECHTMANPatent Examiner
Art Unit 2164
/C.M.S//AMY NG/Supervisory Patent Examiner, Art Unit 2164
