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 .
This action is in response to the application filed on 08/29/2024.
Examiner Notes
Examiner cites paragraphs, figures, and line numbers in the references as applied to
the claims below for the convenience of the applicant. Although the specified citations are
representative of the teachings in the art and are applied to the specific limitations within the individual
claim, other passages and figures may apply as well. It is respectfully requested that, in preparing
responses, the applicant fully consider the references in their entirety as potentially teaching all or part
of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by
the examiner. As a disclaimer, the use of underlining in direct quotes is done by the examiner for
emphasis. Direct quotes are not originally underlined in the published references cited.
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.
Step 1 Analysis:
Claims 1-13 are directed to a method and falls within the statutory category of processes; Claims 14-18 are directed to non-transitory computer-readable media and falls within the statutory category of articles of manufacture; Claims 19-20 are directed to system and falls within the statutory category of processes. Therefore, "Are the claims to a process, machine, manufacture or composition of matter?" Yes. In order to evaluate the Step 2A inquiry "Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?" we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon, or an abstract idea (see MPEP § 2106.04).
Regarding Claims 1, 14, and 19:
Step 2A Prong 1 Analysis:
The Claim limitation recites, selecting a blueprint for configuration of a resource (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. For example, a person may use their mental judgement to select an appropriate blueprint according to the configuration of a resource. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).);
retrieving guardrails corresponding to the resource (This limitation covers performance collecting information. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).);
retrieving, from a knowledge graph, definable variables for the resource (This limitation covers performance collecting information. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).);
generating filtered values for each of the definable values by filtering values for each of the definable variables based on the mapping (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. For example, a person may generate filtered values on pen and paper for each definable value, according to the previous mapping, such as the table mapping previously mentioned above. It is reasonable that a person may filter values according to simple rule(s) such as differentiating whole numbers from decimal numbers, using ordinary pattern recognition as a mental process. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).);
Step 2A Prong 2 Analysis:
inputting the blueprint and the guardrails into an engine (This claim recites the additional element “inputting” which is merely an insignificant extra-solution activity such as transmitting data, which does and not integrate the judicial exception into a practical application (see MPEP § 2106.05(g)), analyzed further below in Step 2B as being well-understood, routine, and conventional.);
receiving, as output from the engine, a mapping of constraints to respective variables of the blueprint (This claim recites the additional element “receiving” which is merely an insignificant extra-solution activity such as gathering data, which does and not integrate the judicial exception directed to mental processes such as “a mapping of constraints to respective variables of the blueprint” into a practical application (see MPEP § 2106.05(g);
generating for display a user interface for configuration of the resource, the user interface
comprising prompts based on the filtered values (This claim recites the additional element “generating for display” which is merely an insignificant extra-solution activity such as displaying data, which does and not integrate the judicial exception above directed to mental process “prompts based on the filtered values” into a practical application (see MPEP § 2106.05(g).)
Claim 14 additionally recites, A non-transitory computer-readable medium comprising memory with instructions encoded thereon, the instructions, when executed by one or more processors, causing the one or more processors to perform operations, the instructions comprising instructions to (This limitation recites additional elements that merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. (See MPEP § 2106.05(f)).);
Claim 19 additionally recites, A system comprising: memory with instructions encoded thereon; and one or more processors that, when executing the instructions, are caused to perform operations comprising (This limitation recites additional elements that merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. (See MPEP § 2106.05(f)).).
Step 2B Analysis:
The additional elements, considering them both individually and in combination, do not amount to significantly more than the judicial exception. As discussed above with respect to the additional elements directed to an insignificant extra-solution activity which are well-understood, routine, and conventional (see MPEP § 2106.05(d)(II) for court decisions recognizing that this activity is well-understood, routine, and conventional), thus do not amount to significantly more than the judicial exception. The claim is not patent eligible.
Regarding Claims 2, 15, and 20:
Step 2A Prong 1 Analysis:
The Claim limitation recites, selecting the blueprint from a plurality of candidate blueprints, the blueprint accommodating each variable of the set of variables (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. For example, a person may observe how each variable in a set of variable needs to be accommodated for, in order to evaluate which blueprint to select. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).).
Step 2A Prong 2 Analysis:
receiving user input of a set of variables for the resource (This claim recites the additional element “receiving” which is merely an insignificant extra-solution activity such as gathering data, which does and not integrate the judicial exception into a practical application (see MPEP § 2106.05(g).).
Step 2B Analysis:
The additional elements, considering them both individually and in combination, do not amount to significantly more than the judicial exception. The claim is not patent eligible.
Regarding Claims 3 and 16:
Step 2A Prong 1 Analysis:
The Claim limitation recites, identifying a subset of the plurality of candidate blueprints, each candidate blueprint of the subset accommodating each variable of the set of variables (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).);
receiving, … , a recommendation of the blueprint (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).).
Step 2A Prong 2 Analysis:
inputting the subset of the plurality of candidate blueprints and profile information of a
user into a machine learning model (This claim recites the additional element “inputting” which is merely an insignificant extra-solution activity such as transmitting data, which does and not integrate the judicial exception into a practical application (see MPEP § 2106.05(g).);
as output from the machine learning model (This limitation recites additional elements that merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. (See MPEP § 2106.05(f)).).
Step 2B Analysis:
The additional elements, considering them both individually and in combination, do not amount to significantly more than the judicial exception. The claim is not patent eligible.
Regarding Claims 4 and 17:
Step 2A Prong 1 Analysis:
The Claim limitation recites, generating a first schema of the configuration for the first environment based on the first environmental variable; and generating a second schema of the configuration for the second environment based on the second environmental variable (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. For example, a person may use pen and paper to create a diagram drawing of the schemas showing the configuration of the environment based on the corresponding variable. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).).
Step 2A Prong 2 Analysis:
receiving user input of a plurality of environmental variables (This claim recites the additional element “receiving” which is merely an insignificant extra-solution activity such as gathering data, which does and not integrate the judicial exception into a practical application (see MPEP § 2106.05(g)).);
a first environmental variable for a first environment of the resource, and a second environmental variable for a second environment of the resource (This limitation recites additional elements that indicate a field of use or technological environment in which to apply a judicial exception. The claim merely recites “a first environment of the resource” and “a second environment of the resource” as a technological environment to perform the abstract ideas. (See MPEP § 2106.05(h)).).
Step 2B Analysis:
The additional elements, considering them both individually and in combination, do not amount to significantly more than the judicial exception. The claim is not patent eligible.
Regarding Claims 5 and 18:
Step 2A Prong 1 Analysis:
The Claim limitation recites, generating a third schema of the configuration for shared inputs that are shared by both the first environment and the second environment, where constraints are combined across the first environment and the second environment for the shared inputs (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. For example, further using examples mentioned previously: the schema diagram being used to add shared inputs created by a person on pen and paper, and using the table mapping on the constraints where a person may use the table mapping to apply the combined constraints to both environments for the shared inputs. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).).
Step 2A Prong 2 and Step 2B Analysis:
The claim does not recite additional elements that integrate the judicial exception into a
practical application nor amounts to significantly more than the judicial exceptions.
Regarding Claim 6:
Step 2A Prong 1 Analysis: See corresponding analysis in Claim 1.
Step 2A Prong 2 Analysis:
The Claim limitation recites, wherein the user interface comprises an indication of constraints that apply to each definable variable (This claim recites the additional element “an indication” which is merely an insignificant extra-solution activity such as displaying data, which does and not integrate the judicial exception into a practical application (see MPEP § 2106.05(g)), analyzed further below in Step 2B as being well-understood, routine, and conventional.).
Step 2B Analysis:
The additional elements do not amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all the additional elements are directed to an insignificant extra-solution activity which is well-understood, routine, and conventional (see MPEP § 2106.05(d)(II) for court decisions recognizing that this activity is well-understood, routine, and conventional.). The claim is not patent eligible.
Regarding Claim 7:
Step 2A Prong 1 Analysis: See corresponding analysis in Claim 6.
Step 2A Prong 2 Analysis:
The Claim limitation recites, wherein the user interface further comprises an indication of which guardrails are enforcing each of the constraints (This claim recites the additional element “an indication” which is merely an insignificant extra-solution activity such as displaying data, which does and not integrate the judicial exception into a practical application (see MPEP § 2106.05(g)), analyzed further below in Step 2B as being well-understood, routine, and conventional.)
Step 2B Analysis:
The additional elements do not amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all the additional elements are directed to an insignificant extra-solution activity which is well-understood, routine, and conventional (see MPEP § 2106.05(d)(II)). The claim is not patent eligible.
Regarding Claim 8:
Step 2A Prong 1 Analysis:
The Claim limitation recites, wherein the filtered values exclude values otherwise possible for
a given definable variable based on constraints imposed by the guardrails (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. For example, a person may use the assistance of pen and paper to create a list of the filtered values with exclusions according to the constraints from the guardrails. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).).
Step 2A Prong 2 and Step 2B Analysis:
The claim does not recite additional elements that integrate the judicial exception into a
practical application nor amounts to significantly more than the judicial exceptions.
Regarding Claim 9:
Step 2A Prong 1 Analysis:
The Claim limitation recites, wherein for a given definable variable, only one filtered value is
generated, and wherein a field for the given definable variable automatically has the one filtered
value pre-populated (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. For example, a person may use the assistance of pen and paper to create a single corresponding filtered value with an existing value to the given definable variable. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).).
Step 2A Prong 2 and Step 2B Analysis:
The claim does not recite additional elements that integrate the judicial exception into a
practical application nor amounts to significantly more than the judicial exceptions.
Regarding Claim 10:
Step 2A Prong 1 Analysis:
The Claim limitation recites, determining a plurality of candidate values that satisfy the constraints (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).);
a score for each of the plurality of candidate values; and pre-populating a candidate value having a highest score relative to other ones of the plurality of candidate values for the given variable (This limitation covers performance in the mind in the form of evaluation and judgement with the assistance of pen and paper. For example, a person may use pen and paper to create a table that keeps track of numerical scores in one column, each row corresponding to another column of candidate values; then the person may observe which row has the highest number score in order to choose that candidate value to pre-populate. Therefore, this limitation recites a mental process. (See MPEP § 2106.04(a)(2), subsection III).).
Step 2A Prong 2 Analysis:
inputting the plurality of candidate values into a machine learning model (This claim recites the additional element “inputting” which is merely an insignificant extra-solution activity such as transmitting data, which does and not integrate the judicial exception into a practical application (see MPEP § 2106.05(g)), analyzed further below in Step 2B as being well-understood, routine, and conventional.);
receiving as output (This claim recites the additional element “receiving” which is merely an insignificant extra-solution activity such as gathering data, which does and not integrate the judicial exception into a practical application (see MPEP § 2106.05(g)), analyzed further below in Step 2B as being well-understood, routine, and conventional.);
wherein a ranked list of the plurality of candidate values is displayed responsive to selection of a user interface element for the given variable (This claim recites the additional element “is displayed” which is merely an insignificant extra-solution activity such as displaying data, and “responsive to selection” which is a post-solution activity which does and not integrate the judicial exception into a practical application (see MPEP § 2106.05(g)), analyzed further below in Step 2B as being well-understood, routine, and conventional.).
Step 2B Analysis:
The additional elements do not amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all the additional elements are directed to an insignificant extra-solution activity which is well-understood, routine, and conventional (see MPEP § 2106.05(d)(II)). The claim is not patent eligible.
Regarding Claim 11:
Step 2A Prong 1 Analysis: See corresponding analysis in Claim 1.
Step 2A Prong 2 Analysis:
The Claim limitation recites, receiving, by way of the user interface, selected ones of the filtered values for each of the definable variables; inputting the configuration with the selected ones of the filtered values into the engine; and receiving an alert as output from the engine, the alert comprising an indication of a violation within the configuration (This claim recites the additional elements which are merely an insignificant extra-solution activity such as “receiving” to gather data; “inputting” to transmit data; “an indication” to display data, which does and not integrate the judicial exception into a practical application (see MPEP § 2106.05(g)), analyzed further below in Step 2B as being well-understood, routine, and conventional.)
Step 2B Analysis:
The additional elements do not amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all the additional elements are directed to an insignificant extra-solution activity which is well-understood, routine, and conventional (see MPEP § 2106.05(d)(II) for court decisions recognizing that this activity is well-understood, routine, and conventional.). The claim is not patent eligible.
Regarding Claims 12 and 13: Although the dependent Claims 12 and 13 do not have 35 U.S.C. 101 directly applied, Claims 12 and 13 are rejected because the 101 issue is inherited from Claim 11.
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.
Claims 1-2, 4-12, 14-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dobrev (U.S. Publication No. 2020/0159573 A1, hereinafter Dobrev) in view of Johnson Jr. et al. (U.S. Publication No. 2018/0181855 A1, hereinafter Johnson).
Regarding Claim 1:
Dobrev discloses,
“A method comprising” (In paragraph [0002], “The present disclosure relates generally to cloud computing and, more particularly, to methods”.)
“selecting a blueprint for configuration of a resource” (In paragraph [0053], “Based on the deployment to be defined, the example customer-customizable deployment blueprints 126 may define one or more dependencies between components”. In paragraph [0055], “Different automation plans 128 may be generated from a single customer-customizable deployment blueprint 126”. In paragraph [0051], “For example, the customer-customizable deployment blueprint 126 … for an online store application may specify a user-configurable number and/or type(s) of web applications (e.g., in the form of a Java web application archive or “WAR” file including … configuration and/or resources files that make up a Java web application”. In paragraph [0058], “manages customer-definable policies (e.g., hardware policies, security policies, network policies, etc.) and definitions for multiple customer-customizable deployments”.);
“retrieving guardrails corresponding to the resource” (In paragraph [0053], “to indicate an installation order of the components during deployment … the developer 118 may specify a dependency … some dependencies between components are not identifiable until after a customer has provided settings for user-configurable parameters”.
In paragraph [0030], “After deployment of a SDDC, the SDDC provides policy-driven automation … customers may select/create policies that cause the SDDC to deploy applications quickly based on policy-driven provisioning”. In paragraph [0058], “Based on the executed automation plan 128, … manages customer-definable policies (e.g., hardware policies, security policies, network policies, etc.) and definitions for multiple customer-customizable deployments”.);
(Examiner’s Note: The examiner uses the Broadest Reasonable Interpretation (BRI) of the claimed “guardrail” to mean restrictions or constraints (Examined case [0086], “the UX would restrict”; Examined case [0087], “which guardrails are enforcing each of the constraints”). In the case of Dobrev, the dependencies are enforcing constraints based on computer system configurations, such as dependencies provided from a customer in “user-configurable parameters” (Dobrev [0053]) (e.g., a dependency constraint may be the installation order).);
“inputting the blueprint and the guardrails into an engine” (In paragraph [0054], “The example automation plan generator 122 … of FIG. 1 generates one or more automation plans 128 based on the customer-customizable deployment blueprint 126 that includes deployment outlines for allocating and configuring resources (e.g., virtual computing resources' cluster size, CPU, memory, networks, etc.) … That is, the automation plan generator 122 compiles a plurality of instructions (e.g., lines of code) programmed by the developer 118 in the customer-customizable deployment blueprint 126 … based on user-configurable parameter values provider by a customer to define types of resources, the number of resources, and/or resource configurations for a customer-specific SDDC deployment”.);
“receiving, as output from the engine, a mapping of constraints to respective variables of the blueprint” (In paragraph [0054], “the automation plan generator 122 … generates the automation plans 128 … includes deployment outlines for allocating and configuring resources”. In paragraph [0055], “automation plans 128 may be generated from a single customer-customizable deployment blueprint 126 … an automation plan 128 is executed … each VM 114 coordinates execution of each task with a centralized deployment module (e.g., the deployment director 124) to ensure that tasks are executed in an order that complies with dependencies specified in the customer-customizable deployment blueprint 126”. In paragraph [0030], “the SDDC to deploy applications quickly based on policy-driven provisioning that dynamically matches resources”.);
“retrieving, [], definable variables for the resource” (In paragraph [0061], “blueprints 126 can specify variables for use in defining tasks or resources”. In paragraph [0068], “The task list 240 of the illustrated example is an execution graph or timeline that lays out dependencies between tasks … so that tasks requiring output resources from other tasks are arranged in a correct order”.);
“generating filtered values for each of the definable values by filtering values for each of the definable variables based on the mapping” (In paragraph [0057], “via the UI 142 to customers. In this manner, the automation deployment manager 140 can receive user-provided parameter values for corresponding ones of the user-configurable parameter options to configure an SDDC and/or an application … automation deployment manager 140 determines dependencies between tasks (e.g., between two or more tasks) in accordance with the executed automation plan 128 and the user-provided parameter values”. In paragraph [0061], “lines of code (LOCs) … the LOCs used to program the customer-customizable deployment blueprints 126 can specify variables for use in defining tasks or resources. Such variables can be flagged or tagged in the customer-customizable deployment blueprints 126 to be compiled in the automation plans 128 as user-configurable parameters”. In paragraph [0054], “The compiled plurality of instructions serve as a machine-executable structure to allocate and/or configure resources for a SDDC deployment and/or an application deployment based on user-configurable parameter values provider by a customer to define types of resources”. );
“and generating for display a user interface for configuration of the resource, the user interface comprising prompts based on the filtered values” (In paragraph [0111], “Each user-configurable parameter 1602a-d is also provided with a “prompt” property to define the text that will be displayed via one or more of the example user interfaces of FIGS. 5-8 to prompt for corresponding user-provided parameter values from the customer user 204. For example, the “prompt” property of the user-configurable parameters 1602a specifies the text “Configure VSAN on Compute POD (Minimum of 3 hosts required)” which is displayed in the example run parameters configuration user interface 800 of FIG. 8”. In paragraph [0062], “the customer can define different deployment configurations through a user-friendly interface (e.g., graphical user interface controls, text fields, etc.) by entering user-provided parameter values for corresponding user-configurable parameters of tasks and resources”.).
Dobrev does not disclose however Johnson discloses,
“from a knowledge graph” (In paragraph [0100], “the one or more variables are identified utilizing a mathematical knowledge graph”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Dobrev by adopting the teachings of a knowledge graph in Johnson; motivated by the common goal for a method that “improves user interactions” (Johnson [0065]) when prompting a user on a user interface (Johnson [0092]), by adapting computer arrangements according to filtered values (Johnson [0010], [0019]).
Regarding Claim 2:
Dobrev discloses,
“receiving user input of a set of variables for the resource” (In paragraph [0068], “The example schedule generator 242 uses the user-provided parameter values received via the user interface 142 in combination with tasks from the task list 240 to generate an example task execution schedule 238 of tasks needed to deploy the SDDC”. In paragraph [0062], “through a user-friendly interface … entering user-provided parameter values for corresponding user-configurable parameters of tasks and resources”. In paragraph [0061], “blueprints 126 can specify variables for use in defining tasks or resources”.);
“and selecting the blueprint from a plurality of candidate blueprints” (In paragraph [0053], “Based on the deployment to be defined, the example customer-customizable deployment blueprints 126 may define one or more dependencies between components”. In paragraph [0055], “Different automation plans 128 may be generated from a single customer-customizable deployment blueprint 126”.);
“the blueprint accommodating each variable of the set of variables” (In paragraph [0061], “the LOCs used to program the customer-customizable deployment blueprints 126 can specify variables for use in defining tasks or resources. Such variables can be flagged or tagged in the customer-customizable deployment blueprints 126 … compiled as user-configurable parameters in the automation plans 128”. In paragraph [0111], “each user-configurable parameter 1602a-d is provided with a “key” property that defines the variable name to reference that user-configurable parameter”.).
Regarding Claim 4:
Dobrev discloses,
“receiving user input of a plurality of environmental variables, a first environmental variable for a first environment of the resource, and a second environmental variable for a second environment of the resource” (In paragraph [0055], “Different automation plans 128 may be generated from a single customer-customizable deployment blueprint 126 to test prototypes (e.g., new application versions), to scale up and/or scale down deployments, and/or to deploy the SDDC and/or the application to different deployment environments 112 (e.g., testing, staging, production)”. In paragraph [0061], “Examples of identifying user-configurable parameters and fixed parameters (non-user-configurable parameters) in a programming environment are described below in connection with FIG. 17. In this manner, some variables in the customer-customizable deployment blueprints 126 result in user-configurable parameters in the automation plans 128 that a customer (e.g., the customer user 204 of FIG. 2) can set to customize deployments”. In paragraph [0054], “an application deployment based on user-configurable parameter values provider by a customer to define types of resources”.
In paragraph [0030], “An SDDC can be deployed as a private cloud, a hybrid cloud, or a public cloud and can run on multiple hardware stacks, hypervisors, and clouds”. In paragraph [0032], “The improvements to cloud management systems … disclosed herein may be utilized individually and/or in any combination”. In paragraph [0039], “a SDDC (or a pool of linked SDDCs) may include multiple different virtualization environments”. In paragraph [0030], “SDDC provides policy-driven automation to enable provisioning and ongoing management of logical compute resources … customers may select/create policies … that dynamically matches resources”.);
(Examiner’s Note: The examiner’s BRI of the claimed “environment” is a type of setting, such as a type of setting in how resources are used. For example, as supported in the examined case’s paragraph [0074], “generating configuration for multiple environments at once (e.g., deploying resources to development, staging, and production environments)”; Similarly, Dobrev states in paragraph [0055], “different deployment environments 112 (e.g., testing, staging, production)”.);
“generating a first schema of the configuration for the first environment based on the first environmental variable; and generating a second schema of the configuration for the second environment based on the second environmental variable” (In paragraph [0055], “Different automation plans 128 may be generated from a single customer-customizable deployment blueprint 126 … and/or to deploy the SDDC and/or the application to different deployment environments 112 (e.g., testing, staging, production)”. In paragraph [0061], “some variables in the customer-customizable deployment blueprints 126 result in user-configurable parameters in the automation plans 128”.);
(Examiner’s Note: The claimed “schema” is mapped to each of Dobrev’s different “automation plan 128” (also referred to as “automation plan”).).
Regarding Claim 5:
Dobrev discloses,
“generating a third schema of the configuration for shared inputs that are shared by both the first environment and the second environment” (In paragraph [0062], “An example task represents a single, well-defined action such as deploying, configuring, or creating a resource. In some instances, an example task consumes one or more resources, which constitute one or more inputs to the task”. In paragraph [0112], “FIG. 17 shows example programming language that implements a resource definition 1702 in an automation plan configuration file (e.g., a configuration file of one of the automation plans 128 of FIGS. 1 and 2) that may be used to define resources as inputs to tasks”. Further in paragraph [0112], “An example “path” property 1704 of the resource to be defined indicates the path or configuration file for a corresponding automation plan to be imported … The resource definition of the illustrated example includes a “repeat” property 1706 which enables creating multiple ones of the resource in a scalable manner”.
In paragraph [0054], “configure resources for a SDDC deployment and/or an application deployment based on user-configurable parameter values provider by a customer to define types of resources, the number of resources, and/or resource configurations for a customer-specific SDDC deployment. In the illustrated example, the automation plan generator 122 generates the automation plans 128”.
In paragraph [0039], “a SDDC … may include multiple different virtualization environments”. In paragraph [0042], “if an end-user customer wants four central virtualization management nodes … examples disclosed herein enable accomplishing this by editing user-configurable parameters in configuration files (e.g., JSON configuration files) of an automation plan … higher-level primitives provided by examples disclosed herein can be implemented to match concepts (e.g., high-level primitives for resource abstraction, resource pooling, and/or resource automation) defined in SDDC stacks from different vendors (e.g., a VMware SDDC stack)”.);
“where constraints are combined across the first environment and the second environment for the shared inputs” (In paragraph [0097], “the dependency determiner 244 selects a task from the task list 240 that is to be executed to allocate or provision a resource for use in the SDDC 202”. In paragraph [0113], “The user-provided parameter values for the user-configurable parameters 1710 may be defined at any suitable time during a customer customization phase of an automation plan (e.g., the automation execution phase of FIGS. 12A and 12B) and used throughout any resource or task definition that refers to those user-configurable parameters 1710”.
In paragraph [0059], “the first DEM 146a includes a first set of characteristics and is physically located at a first location 148a. The second DEM 146b includes a second set of characteristics and is physically located at a second location 148b … For example, a DEM may include hardware particularly suited for performance of certain tasks (e.g., high-end calculations), may be located in a desired area (e.g., for compliance with local laws that require certain operations to be physically performed within a country's boundaries), may specify a location or distance to other DEMS for selecting a nearby DEM (e.g., for reducing data transmission latency), etc. Thus, the example automation deployment manager 140 annotates customer-customizable deployment blueprints 126 with capabilities that can be performed by a DEM that is labeled with the same or similar capabilities.”.).
Regarding Claim 6:
Dobrev discloses,
“wherein the user interface comprises an indication of constraints that apply to each definable variable” (In paragraph [0010], “FIG. 5 illustrates an example main deployment automation configuration user interface that may be displayed to a customer to specify user-configurable parameter settings for customizing deployment of an SDDC”. In paragraph [0062], “through a user-friendly interface … entering user-provided parameter values for corresponding user-configurable parameters of tasks and resources”. In paragraph [0061], “blueprints 126 can specify variables for use in defining tasks or resources … some variables in the customer-customizable deployment blueprints 126 result in user-configurable parameters in the automation plans 128 that a customer (e.g., the customer user 204 of FIG. 2) can set to customize deployments”.).
Regarding Claim 7:
Dobrev discloses,
“wherein the user interface further comprises an indication of which guardrails are enforcing each of the constraints” (In paragraph [0058], “Based on the executed automation plan 128, the example automation deployment manager 140 of the illustrated example manages customer-definable policies (e.g., hardware policies, security policies, network policies, etc.) and definitions for multiple customer-customizable deployments … based on pre-prepared automation plans 128 and user-configurable parameter options”. In paragraph [0057], “the automation deployment manager 140 displays user-configurable parameter options as user interface controls … via the UI 142 to customers. In this manner, the automation deployment manager 140 can receive user-provided parameter values for corresponding ones of the user-configurable parameter options to configure an SDDC and/or an application for deployment based on the executed automation plan 128 and the user-provided parameter values”.
In paragraph [0119], “FIG. 22 shows an example user interface 2200 to enable user-entry of values for resource properties to build a corresponding resource input list for a deployment. In the illustrated example, a plurality of user-configurable license parameters 2202 via which a corresponding automation plan can receive product or component license keys via user-provided parameter values from the customer user 204 to specify corresponding components or products from which to build resource input lists for a deployment”.).
Regarding Claim 8:
Dobrev discloses,
“wherein the filtered values exclude values otherwise possible for a given definable variable based on constraints imposed by the guardrails” (In paragraph [0071], “Conditional task execution allows omission of a task from the task execution schedule 238 … omission of the task can be configured in advance … the conditional task execution can be used to determine during execution of the task execution schedule 238 to not execute a scheduled task of the task execution schedule 238 based on detecting that the resource to be produced by that task is already provided externally from the deployment execution”.
In paragraph [0096], “The example schedule generator 242 associates the user-provided parameter values for the user-configurable parameters with corresponding tasks to be executed as part of the automation plan(s) 128”. In paragraph [0061], “blueprints 126 can specify variables for use in defining tasks or resources … some variables in the customer-customizable deployment blueprints 126 result in user-configurable parameters in the automation plans 128 … set to customize deployments”. In paragraph [0058], “Based on the executed automation plan 128, the example automation deployment manager 140 of the illustrated example manages customer-definable policies … and definitions for multiple customer-customizable deployments … based on pre-prepared automation plans 128 and user-configurable parameter options”. In paragraph [0069], “the automation deployment manager 140 is provided with an example dependency determiner 244 to determine dependencies between tasks in the task list 240 to schedule the tasks for executing in a time-efficient manner … to generate a time-efficient task execution schedule 238”.).
Regarding Claim 9:
Dobrev discloses,
“wherein for a given definable variable, only one filtered value is generated, and wherein a field for the given definable variable automatically has the one filtered value pre-populated” (In paragraph [0111], “Each user-configurable parameter 1602a-d is also provided with a “defaultValue” property that defines a default parameter value for the corresponding user-configurable parameter”.
In paragraph [0111], “each user-configurable parameter 1602a-d is provided with a “key” property that defines the variable name to reference that user-configurable parameter 1602a-d … parameter 1602a-d is also provided with a “prompt” property … to prompt for corresponding user-provided parameter values from the customer user”.).
Regarding Claim 10:
Dobrev discloses,
“wherein for a given variable, generating the filtered values comprises: determining a plurality of candidate values that satisfy the constraints; inputting the plurality of candidate values into a machine learning model; receiving as output a score for each of the plurality of candidate values; and pre-populating a candidate value having a highest score relative to other ones of the plurality of candidate values for the given variable, wherein a ranked list of the plurality of candidate values is displayed responsive to selection of a user interface element for the given variable”
Regarding Claim 11:
Dobrev discloses,
“receiving, by way of the user interface, selected ones of the filtered values for each of the definable variables; inputting the configuration with the selected ones of the filtered values into the engine; and receiving an alert as output from the engine, the alert comprising an indication of a violation within the configuration” (In paragraph [0068], “The example schedule generator 242 uses the user-provided parameter values received via the user interface 142 in combination with tasks from the task list 240 to generate an example task execution schedule 238 of tasks needed to deploy the SDDC”. In paragraph [0079], “a graphical user interface associated with a front end of the load balancer 310 guides a customer through one or more questions to determine system requirements for the installation”. In paragraph [0088], “The automated deployment status user interface … to display progress statuses 902 of different tasks of the task execution schedule 238 … when a cursor is placed over a progress bar, the example UI 142 displays a status overlay window 904 listing status of different operations of a corresponding task … the status overlay window 904 shows operations that have failed and operations that were skipped”. In paragraph [0090], “the customer user 204 can click on a status bar to view detailed information concerning a failure of a task. Such information can include … a missing resource error”.).
Regarding Claim 12:
Dobrev discloses,
“wherein the alert comprises a link to a source of the violation” (In paragraph [0088], “display progress statuses 902 of different tasks of the task execution schedule 238 that are executed to run the automated deployment of the SDDC … UI 142 displays a status overlay window 904 listing status of different operations of a corresponding task … the status overlay window 904 shows operations that have failed and operations that were skipped”. In paragraph [0090], “a status bar to view detailed information concerning a failure of a task. Such information can include … a missing resource error”.
In paragraph [0112], “FIG. 17 shows example programming language that implements a resource definition 1702 in an automation plan configuration file … that may be used to define resources as inputs to tasks … An example “path” property 1704 of the resource to be defined indicates the path or configuration file for a corresponding automation plan”.).
Regarding Claim 14:
Dobrev discloses,
“A non-transitory computer-readable medium comprising memory with instructions encoded thereon, the instructions, when executed by one or more processors, causing the one or more processors to perform operations, the instructions comprising instructions to” (In paragraph [0091], “Flowcharts representative of example machine readable instructions that may be executed to implement the example application director 106 and/or the example cloud manager 138 or portions thereof of FIG. 1 are shown in FIGS. 11, 12A, and 12B … the machine readable instructions include programs for execution by a processor”. In paragraph [0092], “processes of FIGS. 11, 12A, and 12B may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium”.)
“select a blueprint for configuration of a resource” (In paragraph [0053], “Based on the deployment to be defined, the example customer-customizable deployment blueprints 126 may define one or more dependencies between components”. In paragraph [0055], “Different automation plans 128 may be generated from a single customer-customizable deployment blueprint 126”. In paragraph [0051], “For example, the customer-customizable deployment blueprint 126 … for an online store application may specify a user-configurable number and/or type(s) of web applications (e.g., in the form of a Java web application archive or “WAR” file including … configuration and/or resources files that make up a Java web application”. In paragraph [0058], “manages customer-definable policies (e.g., hardware policies, security policies, network policies, etc.) and definitions for multiple customer-customizable deployments”.);
“retrieve guardrails corresponding to the resource” (In paragraph [0053], “to indicate an installation order of the components during deployment … the developer 118 may specify a dependency … some dependencies between components are not identifiable until after a customer has provided settings for user-configurable parameters”. In paragraph [0030], “After deployment of a SDDC, the SDDC provides policy-driven automation … customers may select/create policies that cause the SDDC to deploy applications quickly based on policy-driven provisioning”. In paragraph [0058], “Based on the executed automation plan 128, the example automation deployment manager 140 of the illustrated example manages customer-definable policies (e.g., hardware policies, security policies, network policies, etc.) and definitions for multiple customer-customizable deployments”.);
“input the blueprint and the guardrails into an engine” (In paragraph [0054], “The example automation plan generator 122 … of FIG. 1 generates one or more automation plans 128 based on the customer-customizable deployment blueprint 126 that includes deployment outlines for allocating and configuring resources (e.g., virtual computing resources' cluster size, CPU, memory, networks, etc.) … That is, the automation plan generator 122 compiles a plurality of instructions (e.g., lines of code) programmed by the developer 118 in the customer-customizable deployment blueprint 126 … based on user-configurable parameter values provider by a customer to define types of resources, the number of resources, and/or resource configurations for a customer-specific SDDC deployment”.);
“receive, as output from the engine, a mapping of constraints to respective variables of the blueprint” (In paragraph [0054], “the automation plan generator 122 … generates the automation plans 128 … includes deployment outlines for allocating and configuring resources”. In paragraph [0055], “automation plans 128 may be generated from a single customer-customizable deployment blueprint 126 … an automation plan 128 is executed … each VM 114 coordinates execution of each task with a centralized deployment module (e.g., the deployment director 124) to ensure that tasks are executed in an order that complies with dependencies specified in the customer-customizable deployment blueprint 126”. In paragraph [0030], “the SDDC to deploy applications quickly based on policy-driven provisioning that dynamically matches resources”.);
“retrieve, [], definable variables for the resource” (In paragraph [0061], “blueprints 126 can specify variables for use in defining tasks or resources”. In paragraph [0068], “The task list 240 of the illustrated example is an execution graph or timeline that lays out dependencies between tasks … so that tasks requiring output resources from other tasks are arranged in a correct order”.);
“generate filtered values for each of the definable values by filtering values for each of the definable variables based on the mapping” (In paragraph [0057], “via the UI 142 to customers. In this manner, the automation deployment manager 140 can receive user-provided parameter values for corresponding ones of the user-configurable parameter options to configure an SDDC and/or an application … automation deployment manager 140 determines dependencies between tasks (e.g., between two or more tasks) in accordance with the executed automation plan 128 and the user-provided parameter values”. In paragraph [0061], “lines of code (LOCs) … the LOCs used to program the customer-customizable deployment blueprints 126 can specify variables for use in defining tasks or resources. Such variables can be flagged or tagged in the customer-customizable deployment blueprints 126 to be compiled in the automation plans 128 as user-configurable parameters”. In paragraph [0054], “The compiled plurality of instructions serve as a machine-executable structure to allocate and/or configure resources for a SDDC deployment and/or an application deployment based on user-configurable parameter values provider by a customer to define types of resources”.);
“and generate for display a user interface for configuration of the resource, the user interface comprising prompts based on the filtered values” (In paragraph [0111], “Each user-configurable parameter 1602a-d is also provided with a “prompt” property to define the text that will be displayed via one or more of the example user interfaces of FIGS. 5-8 to prompt for corresponding user-provided parameter values from the customer user 204. For example, the “prompt” property of the user-configurable parameters 1602a specifies the text “Configure VSAN on Compute POD (Minimum of 3 hosts required)” which is displayed in the example run parameters configuration user interface 800 of FIG. 8”. In paragraph [0062], “the customer can define different deployment configurations through a user-friendly interface (e.g., graphical user interface controls, text fields, etc.) by entering user-provided parameter values for corresponding user-configurable parameters of tasks and resources”.).
Dobrev does not disclose however Johnson discloses,
“from a knowledge graph” (In paragraph [0100], “the one or more variables are identified utilizing a mathematical knowledge graph”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Dobrev by adopting the teachings of a knowledge graph in Johnson; motivated by the common goal for a method that “improves user interactions” (Johnson [0065]) when prompting a user on a user interface (Johnson [0092]), by adapting computer arrangements according to filtered values (Johnson [0010], [0019]).
Regarding Claim 15:
Dobrev discloses,
“the instructions further comprising instructions to: receive user input of a set of variables for the resource” (In paragraph [0068], “The example schedule generator 242 uses the user-provided parameter values received via the user interface 142 in combination with tasks from the task list 240 to generate an example task execution schedule 238 of tasks needed to deploy the SDDC”. In paragraph [0062], “through a user-friendly interface … entering user-provided parameter values for corresponding user-configurable parameters of tasks and resources”. In paragraph [0061], “blueprints 126 can specify variables for use in defining tasks or resources”.);
“and select the blueprint from a plurality of candidate blueprints” (In paragraph [0053], “Based on the deployment to be defined, the example customer-customizable deployment blueprints 126 may define one or more dependencies between components”. In paragraph [0055], “Different automation plans 128 may be generated from a single customer-customizable deployment blueprint 126”.);
“the blueprint accommodating each variable of the set of variables” (In paragraph [0061], “the LOCs used to program the customer-customizable deployment blueprints 126 can specify variables for use in defining tasks or resources. Such variables can be flagged or tagged in the customer-customizable deployment blueprints 126 … compiled as user-configurable parameters in the automation plans 128”. In paragraph [0111], “each user-configurable parameter 1602a-d is provided with a “key” property that defines the variable name to reference that user-configurable parameter”.).
Regarding Claim 17:
Dobrev discloses,
“the instructions further comprising instructions to: receive user input of a plurality of environmental variables, a first environmental variable for a first environment of the resource, and a second environmental variable for a second environment of the resource” (In paragraph [0055], “Different automation plans 128 may be generated from a single customer-customizable deployment blueprint 126 to test prototypes (e.g., new application versions), to scale up and/or scale down deployments, and/or to deploy the SDDC and/or the application to different deployment environments 112 (e.g., testing, staging, production)”. In paragraph [0061], “Examples of identifying user-configurable parameters and fixed parameters (non-user-configurable parameters) in a programming environment are described below in connection with FIG. 17. In this manner, some variables in the customer-customizable deployment blueprints 126 result in user-configurable parameters in the automation plans 128 that a customer (e.g., the customer user 204 of FIG. 2) can set to customize deployments”. In paragraph [0054], “an application deployment based on user-configurable parameter values provider by a customer to define types of resources”. In paragraph [0030], “An SDDC can be deployed as a private cloud, a hybrid cloud, or a public cloud and can run on multiple hardware stacks, hypervisors, and clouds”. In paragraph [0032], “The improvements to cloud management systems … disclosed herein may be utilized individually and/or in any combination”. In paragraph [0039], “a SDDC (or a pool of linked SDDCs) may include multiple different virtualization environments”. In paragraph [0030], “SDDC provides policy-driven automation to enable provisioning and ongoing management of logical compute resources … customers may select/create policies … that dynamically matches resources”.);
“generate a first schema of the configuration for the first environment based on the first environmental variable; and generate a second schema of the configuration for the second environment based on the second environmental variable” (In paragraph [0055], “Different automation plans 128 may be generated from a single customer-customizable deployment blueprint 126 … and/or to deploy the SDDC and/or the application to different deployment environments 112 (e.g., testing, staging, production)”. In paragraph [0061], “some variables in the customer-customizable deployment blueprints 126 result in user-configurable parameters in the automation plans 128”.);
Regarding Claim 18:
Dobrev discloses,
“the instructions further comprising instructions to generate a third schema of the configuration for shared inputs that are shared by both the first environment and the second environment” (In paragraph [0062], “An example task represents a single, well-defined action such as deploying, configuring, or creating a resource. In some instances, an example task consumes one or more resources, which constitute one or more inputs to the task”. In paragraph [0112], “FIG. 17 shows example programming language that implements a resource definition 1702 in an automation plan configuration file (e.g., a configuration file of one of the automation plans 128 of FIGS. 1 and 2) that may be used to define resources as inputs to tasks”. Further in paragraph [0112], “An example “path” property 1704 of the resource to be defined indicates the path or configuration file for a corresponding automation plan to be imported … The resource definition of the illustrated example includes a “repeat” property 1706 which enables creating multiple ones of the resource in a scalable manner”. In paragraph [0054], “configure resources for a SDDC deployment and/or an application deployment based on user-configurable parameter values provider by a customer to define types of resources, the number of resources, and/or resource configurations for a customer-specific SDDC deployment. In the illustrated example, the automation plan generator 122 generates the automation plans 128”. In paragraph [0039], “a SDDC … may include multiple different virtualization environments”. In paragraph [0042], “if an end-user customer wants four central virtualization management nodes … examples disclosed herein enable accomplishing this by editing user-configurable parameters in configuration files (e.g., JSON configuration files) of an automation plan … higher-level primitives provided by examples disclosed herein can be implemented to match concepts (e.g., high-level primitives for resource abstraction, resource pooling, and/or resource automation) defined in SDDC stacks from different vendors (e.g., a VMware SDDC stack)”.);
“where constraints are combined across the first environment and the second environment for the shared inputs” (In paragraph [0097], “the dependency determiner 244 selects a task from the task list 240 that is to be executed to allocate or provision a resource for use in the SDDC 202”. In paragraph [0113], “The user-provided parameter values for the user-configurable parameters 1710 may be defined at any suitable time during a customer customization phase of an automation plan (e.g., the automation execution phase of FIGS. 12A and 12B) and used throughout any resource or task definition that refers to those user-configurable parameters 1710”.).
Regarding Claim 19:
Dobrev discloses,
“A system comprising: memory with instructions encoded thereon; and one or more processors that, when executing the instructions, are caused to perform operations comprising” (In paragraph [0091], “the machine readable instructions include programs for execution by a processor … The programs may be embodied in software stored on a tangible computer readable storage medium”. In paragraph [0006], “FIG. 1 depicts an example system constructed in accordance with the teachings of this disclosure for managing a cloud computing platform”.)
“selecting a blueprint for configuration of a resource” (In paragraph [0053], “Based on the deployment to be defined, the example customer-customizable deployment blueprints 126 may define one or more dependencies between components”. In paragraph [0055], “Different automation plans 128 may be generated from a single customer-customizable deployment blueprint 126”. In paragraph [0051], “For example, the customer-customizable deployment blueprint 126 … for an online store application may specify a user-configurable number and/or type(s) of web applications (e.g., in the form of a Java web application archive or “WAR” file including … configuration and/or resources files that make up a Java web application”. In paragraph [0058], “manages customer-definable policies (e.g., hardware policies, security policies, network policies, etc.) and definitions for multiple customer-customizable deployments”.);
“retrieving guardrails corresponding to the resource” (In paragraph [0053], “to indicate an installation order of the components during deployment … the developer 118 may specify a dependency … some dependencies between components are not identifiable until after a customer has provided settings for user-configurable parameters”. In paragraph [0030], “After deployment of a SDDC, the SDDC provides policy-driven automation … customers may select/create policies that cause the SDDC to deploy applications quickly based on policy-driven provisioning”. In paragraph [0058], “Based on the executed automation plan 128, the example automation deployment manager 140 of the illustrated example manages customer-definable policies (e.g., hardware policies, security policies, network policies, etc.) and definitions for multiple customer-customizable deployments”.);
“inputting the blueprint and the guardrails into an engine” (In paragraph [0054], “The example automation plan generator 122 … of FIG. 1 generates one or more automation plans 128 based on the customer-customizable deployment blueprint 126 that includes deployment outlines for allocating and configuring resources (e.g., virtual computing resources' cluster size, CPU, memory, networks, etc.) … That is, the automation plan generator 122 compiles a plurality of instructions (e.g., lines of code) programmed by the developer 118 in the customer-customizable deployment blueprint 126 … based on user-configurable parameter values provider by a customer to define types of resources, the number of resources, and/or resource configurations for a customer-specific SDDC deployment”.);
“receiving, as output from the engine, a mapping of constraints to respective variables of the blueprint” (In paragraph [0054], “the automation plan generator 122 … generates the automation plans 128 … includes deployment outlines for allocating and configuring resources”. In paragraph [0055], “automation plans 128 may be generated from a single customer-customizable deployment blueprint 126 … an automation plan 128 is executed … each VM 114 coordinates execution of each task with a centralized deployment module (e.g., the deployment director 124) to ensure that tasks are executed in an order that complies with dependencies specified in the customer-customizable deployment blueprint 126”. In paragraph [0030], “the SDDC to deploy applications quickly based on policy-driven provisioning that dynamically matches resources”.);
“retrieving, [], definable variables for the resource” (In paragraph [0061], “blueprints 126 can specify variables for use in defining tasks or resources”. In paragraph [0068], “The task list 240 of the illustrated example is an execution graph or timeline that lays out dependencies between tasks … so that tasks requiring output resources from other tasks are arranged in a correct order”.);
“generating filtered values for each of the definable values by filtering values for each of the definable variables based on the mapping” (In paragraph [0057], “via the UI 142 to customers. In this manner, the automation deployment manager 140 can receive user-provided parameter values for corresponding ones of the user-configurable parameter options to configure an SDDC and/or an application … automation deployment manager 140 determines dependencies between tasks (e.g., between two or more tasks) in accordance with the executed automation plan 128 and the user-provided parameter values”. In paragraph [0061], “lines of code (LOCs) … the LOCs used to program the customer-customizable deployment blueprints 126 can specify variables for use in defining tasks or resources. Such variables can be flagged or tagged in the customer-customizable deployment blueprints 126 to be compiled in the automation plans 128 as user-configurable parameters”. In paragraph [0054], “The compiled plurality of instructions serve as a machine-executable structure to allocate and/or configure resources for a SDDC deployment and/or an application deployment based on user-configurable parameter values provider by a customer to define types of resources”.);
“and generating for display a user interface for configuration of the resource, the user interface comprising prompts based on the filtered values” (In paragraph [0111], “Each user-configurable parameter 1602a-d is also provided with a “prompt” property to define the text that will be displayed via one or more of the example user interfaces of FIGS. 5-8 to prompt for corresponding user-provided parameter values from the customer user 204. For example, the “prompt” property of the user-configurable parameters 1602a specifies the text “Configure VSAN on Compute POD (Minimum of 3 hosts required)” which is displayed in the example run parameters configuration user interface 800 of FIG. 8”. In paragraph [0062], “the customer can define different deployment configurations through a user-friendly interface (e.g., graphical user interface controls, text fields, etc.) by entering user-provided parameter values for corresponding user-configurable parameters of tasks and resources”.).
Dobrev does not disclose however Johnson discloses,
“from a knowledge graph” (In paragraph [0100], “the one or more variables are identified utilizing a mathematical knowledge graph”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Dobrev by adopting the teachings of a knowledge graph in Johnson; motivated by the common goal for a method that “improves user interactions” (Johnson [0065]) when prompting a user on a user interface (Johnson [0092]), by adapting computer arrangements according to filtered values (Johnson [0010], [0019]).
Regarding Claim 20:
Dobrev discloses,
“the operations further comprising: receiving user input of a set of variables for the resource” (In paragraph [0068], “The example schedule generator 242 uses the user-provided parameter values received via the user interface 142 in combination with tasks from the task list 240 to generate an example task execution schedule 238 of tasks needed to deploy the SDDC”. In paragraph [0062], “through a user-friendly interface … entering user-provided parameter values for corresponding user-configurable parameters of tasks and resources”. In paragraph [0061], “blueprints 126 can specify variables for use in defining tasks or resources”.);
“and selecting the blueprint from a plurality of candidate blueprints” (In paragraph [0053], “Based on the deployment to be defined, the example customer-customizable deployment blueprints 126 may define one or more dependencies between components”. In paragraph [0055], “Different automation plans 128 may be generated from a single customer-customizable deployment blueprint 126”.);
“the blueprint accommodating each variable of the set of variables” (In paragraph [0061], “the LOCs used to program the customer-customizable deployment blueprints 126 can specify variables for use in defining tasks or resources. Such variables can be flagged or tagged in the customer-customizable deployment blueprints 126 … compiled as user-configurable parameters in the automation plans 128”. In paragraph [0111], “each user-configurable parameter 1602a-d is provided with a “key” property that defines the variable name to reference that user-configurable parameter”.).
Claims 3 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Dobrev in view of Johnson as applied to Claim 2 above, and further in view of Venkata et al. (U.S. Publication No. 2022/0393956, hereinafter Venkata).
Regarding Claim 3:
Dobrev discloses,
“wherein selecting the blueprint comprises: identifying a subset of the plurality of candidate blueprints” (In paragraph [0059], “Thus, the example automation deployment manager 140 annotates customer-customizable deployment blueprints 126 with capabilities that can be performed by a DEM that is labeled with the same or similar capabilities”.);
“each candidate blueprint of the subset accommodating each variable of the set of variables” (In paragraph [0061], “the LOCs used to program the customer-customizable deployment blueprints 126 can specify variables for use in defining tasks or resources. Such variables can be flagged or tagged in the customer-customizable deployment blueprints 126 to be compiled in the automation plans 128 as user-configurable parameters”.);
Dobrev does not disclose however Johnson discloses,
“inputting [] and profile information of a user into a machine learning model” (In paragraph [0071], “The deep learning may utilize machine learning techniques and/or statistical modeling techniques. The deep learning learns or improves through use and/or based on received user feedback and/or world feedback”. In paragraph [0095], “The user 102 provided user feedback 306 in reply to the chat bot's third answer 304C. This user feedback 306 may be utilized by the chat bot 100 to train or update the deep learning utilized by the chat bot”.);
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Dobrev by adopting the teachings of Johnson; motivated by the common goal for a method that “improves the performance, and/or improves user interactions” (Johnson [0065]), when utilizing “machine learning techniques” (Johnson [0071]).
(Examiner’s Note: The crossed limitation, “the subset of the plurality of candidate blueprints” is taught above in Dobrev.).
Dobrev as modified does not disclose however Venkata discloses,
“and receiving, as output from the machine learning model, a recommendation of the blueprint” (In paragraph [0014], “selecting the solution blueprint for the MEC application may include using a machine learning model to select the solution blueprint from a set of solution blueprints”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Dobrev by adopting the teachings of Venkata; motivated by the common goal to improve service inefficiencies, such as inefficiencies cause by unnecessary communication, “Managing a large number of different services under different conditions poses various challenges” (Venkata [0001]).
Regarding Claim 16:
Dobrev discloses,
“wherein the instructions to select the blueprint comprise instructions to: identify a subset of the plurality of candidate blueprints” (In paragraph [0059], “Thus, the example automation deployment manager 140 annotates customer-customizable deployment blueprints 126 with capabilities that can be performed by a DEM that is labeled with the same or similar capabilities”.);
“each candidate blueprint of the subset accommodating each variable of the set of variables” (In paragraph [0061], “the LOCs used to program the customer-customizable deployment blueprints 126 can specify variables for use in defining tasks or resources. Such variables can be flagged or tagged in the customer-customizable deployment blueprints 126 to be compiled in the automation plans 128 as user-configurable parameters”.);
Dobrev does not disclose however Johnson discloses,
“input [] and profile information of a user into a machine learning model” (In paragraph [0071], “The deep learning may utilize machine learning techniques and/or statistical modeling techniques. The deep learning learns or improves through use and/or based on received user feedback and/or world feedback”. In paragraph [0095], “The user 102 provided user feedback 306 in reply to the chat bot's third answer 304C. This user feedback 306 may be utilized by the chat bot 100 to train or update the deep learning utilized by the chat bot”.);
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Dobrev by adopting the teachings of Johnson; motivated by the common goal for a method that “improves the performance, and/or improves user interactions” (Johnson [0065]), when utilizing “machine learning techniques” (Johnson [0071]).
Dobrev as modified does not disclose however Venkata discloses,
“and receive, as output from the machine learning model, a recommendation of the blueprint” (In paragraph [0014], “selecting the solution blueprint for the MEC application may include using a machine learning model to select the solution blueprint from a set of solution blueprints”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Dobrev by adopting the teachings of Venkata; motivated by the common goal to improve service inefficiencies, such as inefficiencies cause by unnecessary communication, “Managing a large number of different services under different conditions poses various challenges” (Venkata [0001]).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Dobrev in view of Johnson as applied to Claim 11 above, and further in view of Frolovichev et al. (U.S. Publication No. 2020/0137003, hereinafter Frolovichev).
Regarding Claim 13:
Dobrev discloses,
“wherein the alert comprises a selectable option to [] the violation” (In paragraph [0090], “FIG. 10 illustrates an example troubleshooting user interface 1000 that may be used to diagnose failures during the automated deployment of the SDDC 202. In the illustrated example, the customer user 204 can click on a status bar to view detailed information concerning a failure of a task. Such information can include an out-of-storage error, a missing resource error, etc. In some instances, the customer user 204 can fix an error or errors, and click on a continue button to continue execution of the task”.).
Dobrev as modified does not disclose however Frolovichev discloses,
“override” (In paragraph [0013], “by comparing the proposed communication to a set of effective communication policies to selectively identify an effective communication policy violation. In the case of an ineffective communication (204—Yes), a warning is supplied”. In paragraph [0015], “Returning to FIG. 2, the warning can be overridden (208—Yes) by activating send tab”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Dobrev by adopting the teaching of overriding with in Frolovichev; motivated by the common goal to improve inefficiencies in services caused by unnecessary communication, such as “segmenting of those prior communications into statistically definitive effective and ineffective communications” (Frolovichev [0017]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Beza D Nigatu whose telephone number is (571)272-9643. The examiner can normally be reached Monday - Friday 7:30am-3:30pm.
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, Hyung Sough can be reached at (571) 272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BEZA D NIGATU/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights