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 .
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 February 17, 2026 has been entered.
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 argues that the claims as amended do not recite a mental process. Specifically that the implementing of steps and remedial steps based on a determination as to whether the state of the database is healthy or unhealthy are not mental steps. However, Examiner respectfully disagrees. Examiner submits that determining whether a database state is healthy or unhealthy and implementing steps and remedial steps in response to the determination are mental steps that can be performed by a user within a database environment and carried out by one or more generic processors.
As such, Examiner maintains that the claims do recite mental processes.
Applicant argues that the claims as amended recite limitations that integrate the judicial exception into a practical application, specifically that they improve the technical field of database management by managing and implementing updates to databases including monitoring of a healthiness state and implementing error handling to transition from a current state configuration to a target state configuration thereby offering improved reliability and reproducibility. However the monitoring of a healthiness state and implementing error handling to transition from a current state configuration to a target state configuration steps are considered to be mental steps. There are no further details claimed that recite how the error handling is accomplished that would lead one to realize the technical improvement to managing the database configuration- rather the error handling is recited at a high level of generality. Furthermore, merely automating conventional management configuration does not show an improvement to the technical field that would provide a practical application for the judicial exception.
As such, Examiner maintains the 101 rejection of the claims.
Applicant's arguments filed with respect to claims 1-20, as amended, have been fully considered but they are not persuasive.
Referring to claim 1, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., implementing error handling for a failed database configuration step; and implementing a remedial step when a configuration step is unsuccessful) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
All other of 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; 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” 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.
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.
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; 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” 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.
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.
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), and further in view of US Patent 8,949,305 issued to White.
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 [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];
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.
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.
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 [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];
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.
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.
Referring to claims 5, 10 and 18, Horowitz/White 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 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 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 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, 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 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 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/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/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, 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 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
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