DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to RCE filed on 6/9/2026, wherein claims 1-18 are pending. The application claims priority based on CN202211098692.9 dated 9/8/2022.
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-4, 6-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) do not fall within at least one of the four categories of patent eligible subject matter because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1 is directed to an abstract idea without significantly more:
Claim 1 recites in part: “…provide a non-compliant user-defined virtual computer state …compare the first plurality of hardware components and the first plurality of software components with the second plurality of hardware components and the second plurality of software components and to modify the predefined compliant virtual computer state if there are any differences between the first plurality of hardware components and the first plurality of software components with the second plurality of hardware components and the second plurality of software components…” These limitations as drafted, the broadest reasonable interpretation when read in light of the specification, are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion. In particular, Examiner note specification at paragraph 49 teaches “…user interface ….to require the user to make any adjustments that maybe required or to perform other suitable functions….”, clearly showing the providing of desired states by the user and the comparison and modifications/adjustments are forms of mental process that can be performed by a human. Thus, these imitations are reciting a mental process.
This judicial exception is not integrated into a practical application. In particular, the claim recites additional elements: “…system for processing data….a virtual environment management system operating on a processor…a virtual computer operating on the processor…the virtual environment management system is configured to…”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). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Furthermore, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. In particular, Moreover, “…retrieve a predefined compliant virtual computer state for a first plurality of hardware components and a first plurality of software components….” Merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting, and storing data which does not integrate the judicial exception into a practical application. (See, MPEP 2106.05(d)). As such, claim 1 is not patent eligible.
Claim 10 is not patent eligible for the same reasons given for claim 1. wherein the “a method for processing data” are merely steps to apply the abstract idea, thus fails to integrate the judicial exception into a practical application, and directed to routine steps and do not contain any inventive concepts.
In addition, claims 2-9 and 11-18 are also not patent eligible for similar reasons given in respective independent claims because they fail to recite any limitations that integrate the judicial exception of claim 1 into a practical application nor amounts to significantly more than the abstract idea. In particular, claims 24, 6-7 and 11-16 are additional mental process steps or steps performed by humans and claims 8-9 and 17-18 are directed to limitations that merely link the use of the judicial exception to a particular technological environment or field of use, thus does not integrate the judicial exception into a practical application. MPEP 2106.05(h). As such, they are also not patent eligible
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 9 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The following claim terms are unclear and indefinite:
As for claim 9, it is unclear what is meant by “…remediate the compliant virtual computer state configuration by implementing compliant portions of the new target virtual computer desired state in the computing cluster…” because compliant is meant as matching a desired state, a compliant configuration requires no remediation and it is unclear what is being remediated, and what is the object that is being remediated. Moreover, because “the compliant portions” are the parts of the new state with which the cluster already agrees, i.e., portions that claim 8 did not identify as non-compliant. So, implementing them achieves no modification to the cluster at all. However, no implementation of remaining non-compliant portions is performed. It is therefore unclear how the recited operations are supposed to operate. For the purpose of examination, Examiner understands compliance to broadly include node compliance and those nodes that do not comply in addition to state table compliance and other interpretations.
The following terms lacks antecedent basis:
Claim 9: “the compliant virtual computer state configuration”.
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 (i.e., changing from AIA to pre-AIA ) 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.
Claim(s) 1 and 10-13 are rejected under 35 U.S.C. 103 as being unpatentable over Parameshwaran et al. (US PGPUB 2022/0179946), in view of Bethlehem et al. (US PGPUB 2011/0251992), in view of Carpenter et al. (US PGPUB 2017/0026416).
As for claim 1, Parameshwaran teaches a system for processing data (paragraph 7, “…embodiment of a data processing system…”), comprising:
a virtual environment management system operating on a processor and configured to retrieve a predefined compliant virtual computer state [standard template...include one or more default configuration setting values] for a first plurality components (paragraph 31, “…computing resource (e.g., VM or container)…” and paragraph 48, “…settings template for the configuration settings is defined based on the desired computing resources…defining the settings template …includes providing a standard template for the resource type, and can include providing one or more default configuration setting values for the template…” in view of paragraph 50, “…config-parameter “SELinux”…”security Context Constraints (SCC)” teaches obtaining a predefined template in the form of a settings template that includes a standard template with default configuration settings specifying the state of various components of a virtual computer (virtual machine or component of the prior art), wherein the configuration settings include settings for various components such as SELinux and SCC in exemplary config entries, each entry is understood as corresponding to a component. Examiner note, Specification of present application teaches “initial cluster -compliant 102…compliant initial cluster configuration is shown with a host processor that has component 1 with version 1 of software and component 2 with version 1 of software…matches a defined virtual computer desired state that has component 1 with version 1 of software and component 2 with version 1 of software” and “non-compliant 104…user-modified state is an indication of a virtual computer desired state for the user that is different from the defined virtual computer desired state…” and “updated cluster – compliant 106….the non-compliant version 2 of the software for component 2 has been added to defined virtual computer desired states…to accommodate the modifications that have been implemented by the user…” (specification paragraphs 28-30). Thus, it is clear that compliant/non-compliant used in view of the specification is different than common and well-understood meaning of compliance/non-compliance of configuration (i.e., policy based, allowed vs not allowed configurations), instead the current application appears to mean any system kept template configuration is a compliant configuration that includes both initial/default configuration or any updated template configurations, whereas non-compliant means any user supplied changes to the system configurations. In another word, it is directed to starting with an initial template (i.e., default/pre-defined/initial/etc. template), in response to detecting a user desired setting change, update the settings within the initial template with user desired setting. There is no determination of “compliance” as commonly understood in the art. Thus, here a predefined compliant virtual computer state is understood as one that corresponds to a computer state defined in a standard template.);
a virtual computer operating on the processor and configured to provide non-compliant user-defined virtual computer state [user’s configuration settings file /configuration settings or definitions that the user provided] for a second plurality of components (paragraph 31, “…computing resource (e.g., VM or container)…” and paragraph 48, “…user’s configuration settings file…configuration setting desired by the user…configuration settings or definitions that the user provided…” in view of paragraph 50, “…config-parameter “SELinux”…”security Context Constraints (SCC)” teaches obtaining a predefined template in the form of a settings template that includes a standard template with default configuration settings specifying the state of various components of a virtual computer (virtual machine or component of the prior art), wherein the configuration settings include settings for various components such as SELinux and SCC in exemplary config entries, each entry is understood as corresponding to a component. See BRI of “compliant/non-compliant” as discussed under preceding claim limitation mapping.); and
wherein the virtual environment management system is configured to compare the first plurality of components with the second plurality of components and to modify the predefined compliant virtual computer state if there are any differences between the first plurality of components with the second plurality of components (paragraph 48, “compares the two …datasets…to identify one or more user-desired configuration settings for the computing resource…using a comparison method, and when a configuration setting desired by the user is identified…settings template is updated accordingly…the process repeats for each of the configuration settings or definitions that the user provided…” teaching comparing and updating the desired states for the plurality of components to a user desired state (user-desired configuration settings in prior art)).
While Parameshwaran teaches having predefined (standard/default) settings and user provided/desired settings for different components of the virtual computer (paragraph 48 in view of paragraph 50), and that the configurable computing resources includes hardware components (paragraph 55, “…configurable computing resources…network bandwidth, processing, memory, storage…”). However, in the interest of compact prosecution, Examiner note Parameshwaran does not explicitly teach in the exemplary config file entries desired states related to both hardware and software components of a virtual computer.
However, Bethlehem teaches a method of virtual machine template management including virtual machine template include a hardware components and software components (paragraph 224-225, “…the virtual machine ... include …hardware and software configuration…software and hardware settings can be saved as templates …” the software and hardware settings recited are understood as corresponding to the desired state of the software and hardware components that the settings corresponds to). This known technique is applicable to the system of Parameshwaran as they both share characteristics and capabilities, namely, they are directed to VM deployment template management.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Bethlehem would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Bethlehem to the teachings of Parameshwaran would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine template management features into similar systems. Further, applying virtual machine template includes desired state of hardware components and software components to Parameshwaran with a first default virtual machine template and a second user supplied virtual machine template with desired settings for VM components stored accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved security by detecting and/or verifying compliance/non-compliance of templates against a compliant template. (Bethlehem, paragraph 13).
As discussed above, “compliant virtual computer state” refers to default/baseline/initial/pre-defined state and “non-compliant user-defined virtual computer state” refers to a user defined state, and the comparison is not a comparison of compliance of the non-compliant user-defined state and perform any operations based on non-compliance to make it compliant, rather, incorporating user-defined “non-compliant” state to “compliant virtual computer state”, in another word, having current/existing template, and adapting an user desired state into/part of the current template by updating the current/existing template, clearly distinguishing from commonly understood meaning of compliance and compliant state vs non-compliant state. Here, compliance vs non-compliant functionally means different, not that it is not compliant and needs remedy. Nevertheless, while prior art clearly can identify the “non-compliant” user defined virtual computer state is different, in the interest of compact prosecution, Examiner will note that the prior arts do not explicitly teach finding the difference explicitly states finding the user-defined virtual computer state as non-compliant based on policy/rule .
However, Carpenter teaches a known method of deployment template management in a virtualized environment including determining a user-defined virtual computer template is non-compliant (paragraphs 34, “…detect the presence …of template….trigger parser on the template…”, paragraph 40, “syntax or format errors found in the template…” and paragraph 41, “…analyzer…may inspect….for potential issues…against an approved baseline template for compliance… (e.g., with one or more rules)…” teaches evaluating of template for compliance where separate exemplary embodiments of compliance with syntax/format, and compliance with one or more rules used to evaluate against a default/baseline/compliant state/template to determine if the template is compliant or non-compliant.). This known technique is applicable to the system of Parameshwaran and Bethlehem as they both share characteristics and capabilities, namely, they are directed to virtualized environment template management.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Carpenter would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Carpenter to the teachings of Parameshwaran and Bethlehem would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual execution environment template management features into similar systems. Further, applying determining if a user-defined virtual computer template is non-compliant to Parameshwaran and Bethlehem with in response to a non-compliant user-defined virtual computer template content is different than a predefined compliant virtual computer template reconcile the content stored accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow simplified virtual machine deployment. (Carpenter, paragraph 224).
As for claims 10, it contain similar limitations as claim 1 above. Thus, it is rejected under the same rataionales.
As for claim 11, Parameshwaran also generating a user interface control using the virtual environment management system to receive a user confirmation of modifications to the predefined compliant virtual computer state prior to implementing the modifications to the predefined compliant virtual computer state (paragraph 48. While the prior art does not explicitly teach confirming the modifications to the predefined compliant virtual computer states, the prior art teaches Parameshwaran teaches the user supplies the user desired configuration state, and when the system determines what the user desired configuration states are, the default/standard configuration template is then modified. Thus, it would be obvious to a person of ordinary skill in the art that the supply of the user desired configuration state is a form of confirmation that the user is okay with modifying the standard/default template’s desired states with the user supplied states because doing so allows for implementation of user’s desired outcome of changing default settings with user preferences).
In addition, Bethlehem also teaches the same (paragraph 227, “…the administrator can also change machine hardware and software template properties…a summary of all settings is then presented. A create button is provided in the GUI…” the create button is understood as functionally the interface that allows a user to confirm the displayed settings (including settings changed according to user/administrator input)).
As for claim 12, Parameshwaran teaches generating a user interface control using the virtual environment management system to receive a user confirmation to exclude a hardware component or a software component from the predefined compliant virtual computer state prior to implementing modifications to the predefined compliant virtual computer state (paragraph 48, Examiner note the specification does not mention, nor does it teach the meaning of exclusion of a hardware component or a software component from the predefined compliant virtual computer state prior to implementing the modification. The only mention of “confirm” in the specification relates comparison of user submitted desired states and the default/standard states, and whether to let such change proceed (See, Specification, paragraph 40). Thus, “exclusion” is understood as including where components whose states are not affected because the user submitted state changes do not include the corresponding component and thus not changed. Here, prior art compare what the User submitted and compare against the corresponding default/standard template’s values, Thus, it is obvious whatever component user did not submit a different value for the state, are excluded because doing so allows for efficient user specification to effect change to default/standard VM templates).
In addition, Bethlehem also teaches the same (paragraph 227, “…the administrator can also change machine hardware and software template properties…a summary of all settings is then presented. A create button is provided in the GUI…” the create button is understood as functionally the interface that allows a user to confirm the displayed settings (including settings changed according to user/administrator input). Similar to above, any properties not changed is understood as excluded.).
As for claim 13, Parameshwaran also teaches enerating a user interface control using the virtual environment management system to receive a confirmation that modifications to the predefined compliant virtual computer state and an exclusion of a hardware component or a software component from the predefined compliant virtual computer state is approved prior to implementing the modifications to the predefined compliant virtual computer state (paragraph 48).
In addition, Bethlehem also teaches the same (paragraph 227, “…the administrator can also change machine hardware and software template properties…a summary of all settings is then presented. A create button is provided in the GUI…” the create button is understood as functionally the interface that allows a user to confirm the displayed settings (including settings changed according to user/administrator input). Similar to above, any properties not changed is understood as excluded. And confirmation button is understood as user confirmation).
Claim(s) 2-5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Parameshwaran et al. (US PGPUB 2022/0179946), in view of Bethlehem et al. (US PGPUB 2011/0251992), in view of Carpenter et al. (US PGPUB 2017/0026416), in view of Rider (US PGPUB 2011/0173302).
As for claim 2, Parameshwaran teaches the virtual environment management system is configured to generate a user interface control to allow a user to confirm modifications to the predefined compliant virtual computer state prior to implementing the modifications to the predefined compliant virtual computer state on a computing cluster of a hyper-converged infrastructure (paragraph 48. While the prior art does not explicitly teach confirming the modifications to the predefined compliant virtual computer states, the prior art teaches Parameshwaran teaches the user supplies the user desired configuration state, and when the system determines what the user desired configuration states are, the default/standard configuration template is then modified. Thus, it would be obvious to a person of ordinary skill in the art that the supply of the user desired configuration state is a form of confirmation that the user is okay with modifying the standard/default template’s desired states with the user supplied states because doing so allows for implementation of user’s desired outcome of changing default settings with user preferences. In addition, Examiner note regarding “on a computing cluster of a hyper-converged infrastructure”, the only positively recited structure is the user interface control, the clause “prior to implementing the modifications…on a computing cluster of a hyper-converged infrastructure” is an intended future focus of an implementing act that is not recited and does not further limit the claimed system. MPEP 2103(I)©; and 2111.04.).
In addition, Bethlehem also teaches the virtual computer state having plurality of hardware components and plurality of software components (paragraphs 224-225), and teaches the same limitations as Parameshwaran above (paragraph 227, “…the administrator can also change machine hardware and software template properties…a summary of all settings is then presented. A create button is provided in the GUI…” the create button is understood as functionally the interface that allows a user to confirm the displayed settings (including settings changed according to user/administrator input)).
While Parameshwaran and Bethlehem teaches editing of VM templates in networked distributed computing environments with plurality of hosts/servers, thus, the modified desired state configuration of the VMs can be understood as editor/user accept differences or making changes. And while the applicant used the word “or” between the different UI control actions, thus, only confirmation is required. However, in the interest of compact prosecution, Examiner note Parameshwaran, Bethlehem, and Carpenter do not explicitly teach the user interface is configured to allow the user to accept a state configuration, to make changes, and to reject it.
However, Rider teaches a method of VM and cluster template management including configured to generate a user interface providing options for a user to confirm, change or customize including configured to allow the user to accept a proposed configuration (paragraph 34 and 36, “…provide options for a user to confirm….any of the presented cluster configuration information…within the configuration template…” and “…for approval…”), to make changes to the proposed configuration (paragraphs 34 and 36, “provide options for a user to …change….the presented cluster configuration information…” and “…for…modification…” and paragraph 46, “…customize button to customize the configuration settings…” editing the default settings manually in contrast to previous optional acceptance and rejection of the ), or to reject the difference (paragraph 54, “…ability to edit any of the default settings for each …”) prior to applying the configuration to the cluster system (paragraph 46, operation 140). This known technique is applicable to the system of Parameshwaran, Bethlehem, and Carpenter as they both share characteristics and capabilities, namely, they are directed to VM deployment template management.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Rider would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Rider to the teachings of Parameshwaran, Bethlehem, and Carpenter would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine template management features into similar systems. Further, applying accepting, modifying, or rejecting a proposed configuration information inside configuration template to Parameshwaran, Bethlehem, and Carpenter with confirm modifications to the predefined compliant virtual computer state including difference between the first plurality of hardware components and the first plurality of software components and the second plurality of hardware components and the second plurality of software components accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow better automated cluster configuration. (Rider, paragraph 8).
As for claim 3, Parameshwaran also teaches generate a user interface control to allow a user to confirm an exclusion of a hardware component or a software component from the predefined compliant virtual computer state prior to implementing modifications to the predefined compliant virtual computer state, wherein the exclusion is stored in an exclude list, and wherein the virtual environment management system is configured to retain the exclude list for use in generating a future target virtual computer desired state (paragraph 48, Examiner note the specification does not mention, nor does it teach the meaning of exclusion of a hardware component or a software component from the predefined compliant virtual computer state prior to implementing the modification. The only mention of “confirm” in the specification relates comparison of user submitted desired states and the default/standard states, and whether to let such change proceed (See, Specification, paragraph 40). Thus, “exclusion” is understood as including where components whose states are not affected because the user submitted state changes do not include the corresponding component and thus not changed. Here, prior art compare what the User submitted and compare against the corresponding default/standard template’s values, Thus, it is obvious whatever component user did not submit a different value for the state, are excluded because doing so allows for efficient user specification to effect change to default/standard VM templates).
In addition, Bethlehem also teaches the same (paragraph 227, “…the administrator can also change machine hardware and software template properties…a summary of all settings is then presented. A create button is provided in the GUI…” the create button is understood as functionally the interface that allows a user to confirm the displayed settings (including settings changed according to user/administrator input). Similar to above, any properties not changed is understood as excluded.).
Rider also teaches user exclusions are stored (paragraph 35, and paragraph 50), and retaining exclusion records for later use in generating the cluster’s configuration (paragraph 32, “…recorded in the configuration template stored in the configuration database so that they can be applied to the hosts during cluster configuration…” also see paragraph 56).
Refer to claim 2 for the motivation to combine.
As for claim 4, Parameshwaran also teaches generate a user interface control to allow a user to confirm modifications to the predefined compliant virtual computer state and an exclusion of a hardware component or a software component from the predefined compliant virtual computer state prior to implementing the modifications to the predefined compliant virtual computer state, wherein the user interface control is configured to allow the user to identify components added by the user, components with attributes that are pinned by the user, and components excluded by the user (paragraph 48).
In addition, Bethlehem also teaches the same (paragraph 227, “…the administrator can also change machine hardware and software template properties…a summary of all settings is then presented. A create button is provided in the GUI…” the create button is understood as functionally the interface that allows a user to confirm the displayed settings (including settings changed according to user/administrator input). Similar to above, any properties not changed is understood as excluded. And confirmation button is understood as user confirmation).
In addition, Rider teaches a user interface configured to allow the user to identify components added by the user, components with attributes that are pinned by the user, and components excluded by the user (paragraphs 35, 57, 65 teaching added by user. Paragraph 14, “…override one or more of the requirements” at paragraph 14 and user edits to default settings captured and applied during contruction in paragraph 54, and manual, user-fixed per-host values entered in place of defaults at Figs. 8B-8C can be understood as attributes pinned by the user. Paragraphs 35 and 50 teaches excluded by the user similar to claim 3 above.
Refer to claim 2 for the motivation to combine.
As for claim 5, Parameshwaran teaches merging a new predefined virtual computer desired state with the user-defined virtual computer state to generate a new target virtual computer desired state (paragraph 48).
While Parameshwaran and Bethlehem teaches editing of VM templates in networked distributed computing environments with plurality of hosts/servers, thus, the modified desired state configuration of the VMs are considered virtual computer desired state configuration in a computing cluster. However, Examiner note in the event the claim language “configured to modify a computing cluster virtual computer desired state configuration” desired state configuration is not corresponding to virtual computer inside a computing cluster, but instead corresponding to the computer cluster itself, where the computing cluster includes the virtual computer.
Rider teaches modify a computing cluster virtual computer desired state configuration (paragraph 33, “…managing configuration settings within the configuration template, maybe used to construct a configuration template to which each host in a cluster must conform based on specific features requirements for forming the cluster…” paragraph 44, “…”cluster configuration settings maybe ..by …a template configuration module…include network settings…storage settings and hardware configuration profile….” And paragraph 54, “default requirement settings for selected features are rendered….provide the ability to edit any of the default settings for each rendered features…receives the edits and updates the features settings …for the cluster…in the configuration database…” In addition, Examiner note configuration setting here also includes both cluster wide settings and VM specific settings. See, e.g., paragraph 45, “configuration components, such as cluster features, hosts, networking, storage, virtual machines…”) and mediating the computer cluster with the new target virtual computer desired state (paragraphs 31, 14, and 46, and Fig. 2A operation 140).
Refer to claim 2 for the motivation to combine.
As for claim 14, it contain subset of claim limitations of claim 5 above. Thus, it is rejected under the same rationales.
Claim(s) 6-7 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Parameshwaran et al. (US PGPUB 2022/0179946), in view of Bethlehem et al. (US PGPUB 2011/0251992), in view of Carpenter et al. (US PGPUB 2017/0026416), in view of Wasson et al. (US PAT 9424058)
As for claim 6, Parameshwaran teaches the virtual environment management system is configured to generate a user interface control to allow a user to confirm a modifications to component for the predefined compliant virtual computer state prior to implementing the modifications to the component for the predefined compliant virtual computer state wherein the component is a user-provided component that is different from a corresponding component in the predefined compliant virtual computer state, (paragraph 48 in view of paragraph 50 showing each can be a component. While the prior art does not explicitly teach confirming the modifications to the predefined compliant virtual computer states, the prior art teaches Parameshwaran teaches the user supplies the user desired configuration state, and when the system determines what the user desired configuration states are, the default/standard configuration template is then modified. Thus, it would be obvious to a person of ordinary skill in the art that the supply of the user desired configuration state is a form of confirmation that the user is okay with modifying the standard/default template’s desired states with the user supplied states because doing so allows for implementation of user’s desired outcome of changing default settings with user preferences), and wherein the modifications to the component are retained by the virtual environment management system for use in future upgrades to the predefined compliant virtual computer state (paragraph 48. The user modification is retained in the resulting template used thereafter).
In addition, Bethlehem teaches the virtual environment management system is configured to generate a user interface control to allow a user to confirm a modifications to software and hardware component for the predefined compliant virtual computer state prior to implementing the modifications to the hardware component for the predefined compliant virtual computer state (paragraph 227, “…the administrator can also change machine hardware and software template properties…a summary of all settings is then presented. A create button is provided in the GUI…” the create button is understood as functionally the interface that allows a user to confirm the displayed settings (including settings changed according to user/administrator input)) and the modification to the components are retained by the virtual environment management system for use in future upgrades to the predefined compliant computer state (paragraphs 224-225, “settings can be saved as templates…” if they are saved, they can be used in future deployments and upgrades of the template).
While Bethlehem teaches the confirmed component can be hardware components and the hardware component includes elements such as network adapters/SCSI controllers, drives, etc. (Bethlehem, paragraph 191, “…components are used…hardware and software elements…include …operating system, scisi controller, network adapters…drives…storage location…”) and thus, it would have been obvious to a person of ordinary skill in the art to recognize that these elements such as operating system, and the various controllers to be accessed by the VMs implementing the VM template, includes drivers because doing so allows for the virtualized workload to access allocated hardware resources. Nevertheless, in the interest of compact specification, Examiner note they do not explicitly teach the template component includes a driver.
However, Wasson teaches a well-known method of virtual machine deployment utilizing virtual machine templates including VM template includes device driver for the predefined compliant virtual computer state (col. 5, lines 58 – col. 6 line 5, “…virtual machine templates….serves as template for …creation of multiple virtual machines…such as…installation of device drivers in common…”). This known technique is applicable to the system of Parameshwaran, Bethlehem, and Carpenter as they both share characteristics and capabilities, namely, they are directed to VM deployment template management.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Wasson would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Wasson to the teachings of Parameshwaran, Bethlehem, and Carpenter would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine template management features into similar systems. Further, applying VM template includes drivers for the predefined compliant virtual computer state Parameshwaran, Bethlehem, and Carpenter with a virtual environment management system is configured to generate a user interface control to allow a user to confirm a modifications to software and hardware component for the predefined compliant virtual computer state prior to implementing the modifications to the hardware component for the predefined compliant virtual computer state accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would simplified deployment of multiple cloned VMs (Wasson, col. 6, lines 6-10).
As for claim 7, Parameshwaran teaches the virtual environment management system is configured to generate a user interface control to allow a user to confirm modifications to component for the predefined compliant virtual computer state prior to implementing the modifications to the component for the predefined compliant virtual computer state (paragraph 48. While the prior art does not explicitly teach confirming the modifications to the predefined compliant virtual computer states, the prior art teaches Parameshwaran teaches the user supplies the user desired configuration state, and when the system determines what the user desired configuration states are, the default/standard configuration template is then modified. Thus, it would be obvious to a person of ordinary skill in the art that the supply of the user desired configuration state is a form of confirmation that the user is okay with modifying the standard/default template’s desired states with the user supplied states because doing so allows for implementation of user’s desired outcome of changing default settings with user preferences), and wherein the modifications to the component are retained by the virtual environment management system for use in future upgrades to the predefined compliant virtual computer state (paragraph 48. The user modification is retained in the resulting template used thereafter).
In addition, Bethlehem teaches the virtual environment management system is configured to generate a user interface control to allow a user to confirm a modifications to software and hardware component for the predefined compliant virtual computer state prior to implementing the modifications to the hardware component for the predefined compliant virtual computer state (paragraph 227, “…the administrator can also change machine hardware and software template properties…a summary of all settings is then presented. A create button is provided in the GUI…” the create button is understood as functionally the interface that allows a user to confirm the displayed settings (including settings changed according to user/administrator input)) and the modification to the components are retained by the virtual environment management system for use in future upgrades to the predefined compliant computer state (paragraphs 224-225, “settings can be saved as templates…” if they are saved, they can be used in future deployments and upgrades of the template)..
Wasson teaches a well-known method of virtual machine deployment utilizing virtual machine templates including VM template includes a host bus adapter driver for the predefined compliant virtual computer state (col. 5, lines 58 – col. 6 line 5, “…virtual machine templates….serves as template for …creation of multiple virtual machines…such as…installation of device drivers in common…” in view of col. 4, line19, “…a host bus adapter (HBA) interface card 235A configured to connect with a Fiber Channel (FC) network…HBA interface card configured to connect to a SCSI bus…”). Rationale for combine same as claim 6 above.
As for claims 15-16, they contain subset of claim limitations as claims 6-7 above. Thus, they are rejected under the same rationales.
Claim(s) 8-9 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Parameshwaran et al. (US PGPUB 2022/0179946), in view of Bethlehem et al. (US PGPUB 2011/0251992), in view of Carpenter et al. (US PGPUB 2017/0026416), in view of Doherty et al. (US 2022/0179946).
As for claim 8, Parameshwaran also teaches the virtual environment management system is further configured to generate a new target virtual computer desired state from the modified predefined compliant virtual computer state (paragraph 48 teaching a new target generated from the modified predefined compliant state).
While Carpenter teaches using a baseline template, which in combination with Parameshwaran above would be understood as the new target virtual computer desired states to inspect for compliances (paragraph 41), in the interest of compact prosecution, Examiner note Parameshwaran, Bethlehem, and Carpenter do not explicitly teach identifying non-compliant virtual computer desired state configurations of deployed computers in a computer cluster.
However, Doherty teaches a known method of dynamic modification of virtual machine templates and VM deployment using VM templates/updated/modified vm templates including scan a computing cluster to identify a non-compliant virtual computer desired state configuration (paragraph 48, “…determines that the template associated with a VM server type was modified…the monitored instances associated with the modified VM server type template are updated…” teaching monitoring of VM instances for whether they are compliant or non-compliant with the VM template associated with the VM instance. Examiner note, non-compliant virtual computer desired state configuration obviously needs to be identified for the system to modify it to conform to the updated template as a consequence of the disclosed monitoring because doing so allows for identification of target to perform subsequent remedial tasks on.) This known technique is applicable to the system of Parameshwaran, Bethlehem, and Carpenter as they both share characteristics and capabilities, namely, they are directed to VM deployment template management.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Doherty would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Doherty to the teachings of Parameshwaran, Bethlehem, and Carpenter would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine template management features into similar systems. Further, applying scan a computing cluster to identify a non-compliant virtual computer desired state configuration Parameshwaran, Bethlehem, and Carpenter with modify desired hardware and software components for VMs to be deployed in a cluster based on modified VM templates and inspecting against an approved template for compliance accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow better automated VM configuration management. (Doherty, paragraph 8).
As for claim 9, Doherty also teaches modify a non-compliant computing cluster to remediate a virtual computer desired state configuration (paragraph 38, “…monitored instances associated with the modified VM server…template are updated or replaced…” updating or replacing the monitored instances that no longer conform to the template are understood as remediate the Virtual computer desired state configuration.).
Rider teaches applying a target configuration to a computing cluster in which the portion that conform are implemented and alerting to user (Fig. 4D – “4 out of 5 hosts added to the cluster”) while the non-conforming portion is reported to the user for confirmation (paragraph 47, “suitable errors and warnings are rendered at the user interface to alert the user….” Fig. 4F “Try again” and paragraph 77, and paragraph 44 teaching suggested adjustments.)
As for claims 17-18, they contain similar limitations as claim 8-9 above. Thus, they are rejected under the same rationales.
Response to Arguments
Applicant's arguments filed on 6/9/2026 have been fully considered but they are not persuasive for the following reasons.
Applicant argues in the remarks:
Argument I: “…claim 1 recites ‘a virtual environment management system operating on a processor’ and ‘a virtual computer operating on the processor’ that …they are hardware…” (Remarks Pg. 7-8)
Argument II: “…retrieve a predefined compliant virtual computer state for…hardware components and …software components…modify the predefined compliant virtual computer state if there are any differences…” are incapable of being performed in the mind…” (Remarks pg. 7-8)
Argument III: “…claim 1 is also directed to allowable subject matter under the memorandum dated Aug 4, 2025 from Deputy Commissioner for Patents Charles Kim…unless it’s more likely than not…that the claim is ineligible…” (Remarks Pg. 7-8)
Argument IV: “…the reliance on paragraph 49 of the specification is misplaced…existence of a user interface does not transform technical operations into mental process…the claim includes ‘modify the predefined compliant virtual computer state’ which …is a technical operation that produces a concrete change to computer infrastructure…” (Remarks Pg. 8).
Argument V: “…the office improperly dismissed the ‘retrieve’ limitation as insignificant extra solution activity….and is a baseline against which comparison and modification occur, not mere data gathering…” (Remarks Pg. 9)
Argument VI: Examiner improperly construed “compliant” and “non-compliant” as any system-kept template configuration (initial/default) and any user-supplied change to system configurations that this construction improperly uses the prior art instead of the specification. And that Parameshwaran’s “standard template” is ‘not characterized as ‘compliant’” and that the user’s settings file is ‘not characterized as ‘noncompliant;” (Remarks Pg. 9).
Argument VII: Parameshwaran’s comparison and template update ‘occur entirely in the context of homomorphic encryption for secure deployment’ and that a conceptual difference exists because in Parameshwaran the user’s settings ‘are intended to be the deployed configuration.’ Whereas in the claim the compliant state’ itself is modified to accommodate detected differences’ (Remarks Pg. 10-11).
Argument VIII: “…Bethehem …does not modify the template when it ncounters non-compliant software.” (Remarks Pg. 11).
Argument VIIII: “…Carpenter’s compliance analysis is directed to checking whether an IaC template adheres to security policies….not to comparing user-desired hardware/software component states against a baseline template and then modifying the baseline to incorporate user difference. As a result, the stated motivation ….does not provide an articulated reasoning …..to …combine….” (Remarks Pg. 11).
Examiner respectfully disagrees for the following reasons:
With Respect to argument I, see paragraph 5 above. In addition, Examiner note the office does not deny that claim 1 recites a processor, instead, office find that the processor is a generic computer component recited at a high level of generality and that the virtual environment management system and the virtual computer are software executing on that generic processor. Applicant’s own specification defines a software ‘system’ as one ‘that operates on a processor to perform predetermined functions.’and characterizes implementing an algorithm on a processor as a ‘well-known process…[[that]should require no explanation for one of even rudimentary skill in the art…” (Specification paragraph 59). Recitation of generic computer hardware does not remove a claim from the mental-process grouping MPEP 2106.04(A)(2)(III)(C). Thus, Applicant’s argument is unpersuasive.
As for Argument II: See paragraph 5 above. In addition, under the BRI in light of the specification, the claimed “states’ are configuration definitions – sets of entries identifying components and associated software versions. Current application Specification at Fig. 1 and paragraphs 28-30 depicts compliant state as a component 1 with version 1 of software and component 2 with version 1 of software….and similarly for non-compliant user-defined states as well. Fig. 2 presents a complete worked example on a single drawing sheet with predefined state of components 1-5 a user provided state, and the resulting target state Applicant’s own drawings thus set out every input state and the merged output, at the granularity of a handful of components/version entries, within a single sheet of paper. Retrieving such list, receiving a second, comparing the entries, and rewriting the first list where entries differ is observation, evaluation, and judgement that a person can realistically perform in the mind or with pen and paper as demonstrated by applicant’s own drawings and specification. The deployed environments the entries describe may be complex are immaterial to the actual mental process itself, the claim operates on the state data, not on any environment (see, Electric Power Group, 830 F.3d 1350, 1353-54 (Fed. Cir. 2016). Thus, Applicant’s argument is unpersuasive.
Regarding Argument III, see paragraph 5 above. In addition, Applicant’s reliance on 2025 memo is noted, however, the Rejection is consistent with the memorandum, which expressly announces no new practice and directs examiners to existing guidance. No, the articulated reminder applied, that it is more likely than not that claims 1-4 and 6-18 are ineligible for reasons of record and above, this is not a close case resting on mere uncertainty and the mental process are clearly practicable in the human mind and/or with aid of paper and pen as evidenced by applicant’s own Figs. 1-2. The individualized application of the memorandum’s standard is further reflected in the withdrawal of rejection as to claim 5 above. Thus, Applicant’s argument is unpersuasive.
As for Argument IV: See paragraph 5 above. In addition, Examiner strongly disagrees because the object of the recited modification is the predefined compliant virtual computer state, a stored configuration definition, not any computing infrastructure at all. Indeed, the dependent claims supports this, such as claim 3, “….retain…for use in generating a future target virtual computer desired state…” claims 6-7 “…retained…for use in future upgrades to the predefined compliant virtual computer state…” claim 8 the new state is used only to ‘scan…to identify’. No claim other than claim 5 actually made any changes to the computer system itself. Stated another way, the modify step is not producing any concrete change to computer infrastructure at all, it is merely a stored configuration definition that is modified, not any computing infrastructure. Nothing in dependent claims 1-4, 6-8 or 10-18 applies the modified state to any machine at all. No claim changes how the processor, the virtual computer, or any cluster operates. Consequently, Applicant’s argument is not persuasive.
As for Argument V: See paragraph 5 above. In addition, Examiner note retrieval of data is acquisition of the data upon which the abstract comparison operates – necessary data gathering that remains insignificant pre-solution activity. MPEP 2106.05(g), and well-understood, routine, and conventional receiving of stored information (MPEP 2106.05(d). Applicant’s own characterization as “baseline’ for the comparison confirms it is merely an input to the abstract idea. Every mental process needs to obtain inputs to mentally process on, and the need for an input does not integrate the exception into a practical application. Consequently, Applicant’s argument is not persuasive.
As for Argument VI: See paragraph 10 above. In addition, Examiner’s construction is drawn from Application’s own specification at paragraphs 28-30 and Fig. 1. Compliant is one that matches a defined virtual computer desired state, and the non-compliant state is a user-modified state different from the defined virtual computer desired state, and the updated compliant state results from the user’s non-compliant version being added to define virtual computer desired state to accommodate the modifications that have been implemented by the user. Thus, compliance as used in the claims and written specification, is predefined desired-state definition while non-compliance is user-supplied difference from it. No policy or rule-based compliance determination appears anywhere in the claims or specification. Applicant’s own remarks admit to this, “non-compliant refers to a user-modified state that differs from the predefined state, not a state that violates security rules.” (Remarks Pg. 10). Moreover, no requirement exists that the prior art must use the same naming convention as applicant’s claims. Here, under the BRI states are merely stored sets of component/setting entries (Fig. 1-2), define the states as lists of components with software versions. Parameshwaran at paragraph 50 shows the same type of entries for the template. Thus, applicants failed to articulate any actual difference between prior art teachings and existing claim limitations beyond generically asserting they are simply different. As such, Applicant’s argument is unpersuasive.
As to Argument VII, see paragraph 10 above. In addition, Examiner note applicant’s argument is directed to additional features of the prior art, which does not a basis for showing the prior art failed to teach the claim limitations actually claimed in the application. The encrypted environment is merely the context in which the prior art performs the identical operations. Moreover, Parameshwaran specifically teaches modifying the predefined template based on identified differences to the user defined input (paragraph 48). Moreover, conceptual difference as alleged is not a claimed difference. In fact, as repeatedly demonstrated above, the current application and prior art are both directed to accommodate the modifications that wants to be implemented by the user. Consequently, Applicant’s arguments are unpersuasive.
As for Argument VIII, see paragraph 10 above. In addition, Examiner note Bethehem is used only to teach virtual machine templates that carry both state of hardware components and software components. It is not relied upon for modifying any template, the comparing and modifying limitations are already taught by the primary art as set forth in the office action. No law, regulation, or court cases require each and every art in an obviousness based rejection to teach limitations already disclosed by another art in the combination. Thus, applicants’ arguments are unpersuasive.
As for Argument VIIII, see paragraph 10 above. In addition, Examiner note Applicant’s own argument defeat itself. In particular, Applicant argues that the claimed ‘non-compliant’ state is ‘not a state that violates security rules’ as applicant concedes the claims require no policy or rule-based compliance determination. Thus, Parameshwaran alone already identified each user-desired setting that differs from the default template (paragraph 48). Carpenter is merely applied in the interest of compact prosecution for the express determination that a user-defined template is non-compliant. An art cited to bolster a limitation the primary art already renders obvious under Applicant’s own construction cannot be a basis for a patentability distinction. Moreover, Carpenter is not limited to firewall rule examples. It also teaches it can generically inspect a template ‘against an approved baseline template for compliance…” (paragraph 41), evaluating a user template against an approved baseline template is comparing a user-defined state against a predefined compliant (approved) state. The exemplary rules do not limit reference to its examples. Consequently, applicants’ argument is unpersuasive.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached M-F 10am-6pm.
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, Lewis Bullock can be reached on 5712723759. 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.
/KEVIN X LU/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
