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 amendment filed on 12/02/2025, 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-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 2-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 § 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-4 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 claim 2, Parameshwaran also teaches the virtual environment management system is configured to generate a user interface control to allow a user to confirm the 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 3, Parameshwaran 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 the 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 4, Parameshwaran also teaches the virtual environment management system is configured to generate a user interface control to allow a user to confirm the 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 (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).
As for claims 10-13, they contain similar limitations as claims 1-4 above. Thus, they are rejected under the same rationales.
Claim(s) 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 5, 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, in the interest of compact prosecution, 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, Parameshwaran, Bethlehem, and Carpenter do not explicitly teach configured to modify a computing cluster virtual computer desired state configuration.
However, Rider teaches a method of VM and cluster template management including configured to 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…”). 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 to modify a computing cluster virtual computer desired state configuration to Parameshwaran, Bethlehem, and Carpenter with modify desired hardware and software components for VMs to be deployed in a cluster stored 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 14, it contain similar limitations as 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 Doherty et al. (US 20220179946).
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 (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 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)).
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 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 (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 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)).
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 similar 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 20220179946).
As for claim 8, while Parameshwaran, Bethlehem, and Carpenter teaches updating a default vm/cluster template and identifying a non-compliant virtual computer desired state template, they 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 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.).
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 with respect to claim(s) 1-18 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In addition, Applicant argues in the remarks dated 12/2/2025:
Argument I: “…the claims are directed to patentable subject matter…because they involve specific technical steps that changes the configuration of hardware, integrate the abstract idea into a practical application…” (App. Arg. Pg. 6-7)
Examiner respectfully disagrees for the following reasons:
With Respect to argument I, see paragraph 5 above. In addition, Examiner note applicant’s argument is not supported by the substantive claim limitations. In particular, applicant argues its patent eligible because they involve steps that “changes the configuration of hardware”, which is not found anywhere. Indeed, Examiner note claim merely teaches a predefined compliant virtual computer state for a first plurality of hardware components and a first plurality of software components, and a user—defined virtual computer state for a second plurality of hardware components and a second plurality of software components, they are merely information relating to the state of 2 distinct set of components. Indeed, it’s a predefined state and a user-defined state for different sets of components, it is not the hardware nor software components themselves. In another word, “state” as claimed is merely a list of settings that can clearly be kept in the mind. Here the only change claimed is “modify the predefined compliant virtual computer state”, which presumably include modifying it to be similar to the user-defined virtual computer state, under the BRI, such a modification includes mere mental notation of a change in state information. Any modification of the states is understood as modification of state setting information that can be hosted in a file or mind. There is no claim of any modification to a component, let alone hardware as alleged by the applicant. Consequently, the argument is unpersuasive.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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