DETAILED ACTION Claims 17-20 objected to for minor informalities. Claims 1, 4-5, 9, 12-13, and 17-18 are rejected under 35 USC § 102. Claims 2-3, 6-8, 10-11, 14-16, and 19-20 are rejected under 35 USC § 103. Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Objections Claim(s) 17-20 is/are directed to a “ computer-readable storage medium .” The present specification states that the terms “machine- storage medium,” “device- storage medium,” and “computer- storage medium” specifically “exclude carrier waves, modulated data signals, and other such media.” Specification, ¶ 85. The present specification also states that the terms “machine- readable medium,” “computer- readable medium,” and “device- readable medium” “include … transmission media” and “carrier waves/modulated data signals.” Id. at ¶ 88. This becomes an issue because claims 17-20 are directed to a “computer- readable storage medium.” This combination of terms is not expressly defined in the specification. It is questionable whether Examiner should interpret the claimed medium as the statutory storage media or the non-statutory readable media. Examiner objects to claims 17-20, and requests the claims be amended to “ computer-storage medium ” to match the terminology in the specification and avoid any possible non-statutory misinterpretation. For purposes of examination , Examiner interprets the currently recited " computer-readable storage medium " as only including non-transitory mediums. If Applicant intends for the claimed computer-readable storage media to include non-statutory transitory embodiments, then advise in a response to this Office Action and rejections under 35 USC § 101 will be forthcoming. Claim Rejections - 35 USC § 102 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale , or otherwise available to the public before the effective filing date of the claimed invention. Claims 1, 4-5, 9, 12-13, and 17-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Nidugala et al., U.S. PG-Publication No. 2017/0315838 A1. Claim 1 Nidugala discloses a computer-implemented method for managing virtual machines ("VMs") executing across a plurality of nodes in a data center . Nidugala discloses methods “for migration of virtual machines (VMs). Criteria for operating of the VM is scored, and a “suitability score is computed for each particular servers amongst a set of servers based on the satisfaction of the … criterion by the particular server” (servers → nodes). Nidugala ¶¶ 13-14. Nidugala discloses the method comprising: receiving, by a VM balancing service executing on a server, utilization metrics for a plurality of VMs provisioned for and executing on a node of the plurality of nodes, and utilization metrics for the plurality of nodes . The method is implemented using a system 100 comprising a VM migration module 104, resource manager module 208, and load balancing module 210 (i.e., VM balancing service executing on a server ) . Id. at ¶ 31; FIG. 2. The disclosure states that “VM refers to any, some, or all VMs, such as VM 220, which are hosted on the source server 202.” Resource manager module 208 “obtains performance metrics of the source server 202,” including “CPU utilization, RAM utilization, storage utilization, and network bandwidth utilization.” The resource utilization information of source server 202 “is the sum of utilization of the resources by all the VMs that are hosted on the source server 202 ” (i.e., the utilization metrics for the plurality of nodes). Id. at ¶ 37. The method also “can obtain the rate of request for different types of transactions,” including “how much time was consumed to service a request.” The “rate of request is … calculated as number of calls serviced per unit time” (rate of request → utilization metric of the provisioned VM) Id. at ¶ 39. The performance of the VM “includes the performance of the workload running on the VM” (performance of the workload → performance of a provisioned VM). If the expected performance of the VM is not achieved, “the VM migration module 104 determines that the VM is to be migrated from the source server 202.” Id. at ¶¶ 46-47. Nidugala discloses analyzing, by the VM balancing service, the received utilization metrics for the plurality of VMs and nodes to identify one or more VMs that satisfy migration criteria based on underutilization of resources . Nidugala discloses that the “load of a server refers to the resource utilization of the server” monitored by load balancing module 210. VM migration module 104 can determine that the VM is to be migrated from the source server 202 … when load balancing module 210 communicates to the VM migration module 104 that the load of the source server 202 is below a second threshold.” This indicates that “all VMs hosted on the source server 202 may be migrated to other servers … without any significant performance overhead to the other servers.” Then the source server 202 “can be deployed in a low power mode, such as an off mode or a sleep mode.” Id. at ¶ 51. Nidugala discloses determining, by the VM balancing service, based on the analyzing, a migration plan for migrating the identified one or more VMs from their respective nodes to one or more other nodes . When the load of source server 202 “decreases below the second threshold, the VM migration module 103 migrates the VM from the source server 202.” Further, the VM migration module 103 can migrate the VM from the source server 202 “when the utilization of any of the resources drops below the second threshold.” Id. at ¶ 51. The owner of source server 202 “can provide instructions to the VM migration module 104 to migrate all the VMs,” and “provide instructions for migration of the VM” (instructions for migration → migration plan). Id. at ¶ 54. Nidugala discloses transmitting, by the VM balancing service, instructions to implement the migration plan, wherein the instructions cause migration of at least one identified VM from a first node to a second node . The load balancing module 210 (i.e., VM balancing service), “communicates with the monitoring agent(s) 302 periodically to determine the load of he source servers 202, so that if the load breaches … the second threshold, the VM migration module 104 can be informed.” Id. at ¶ 51. Based on performance metrics for each particular server, the VM migration nodule “determines the servers that have the resources for usage by the VM.” The VM migration module 10 4 “utilizes compatibility information for each particular server … to determine whether the VM is compatible with the server or not.” Id. at ¶¶ 56-58. The method determines “suitability scores for the plurality of candidate servers” based on criteria, and a set of servers is shortlisted “having suitability score greater than a threshold.” The server “having a higher capacity utilization compares to the other servers is selected to be the destination server.” The VM “can then be migrated to the destination server” (source server to a destination server → first node to a second node). Id. at ¶ 66. Claim 4 Nidugala discloses wherein the migration criteria are further based on an overall utilization level of the node on which the VM is executing, such that migration is triggered when the node utilization is below a threshold . Nidugala discloses that the “load of a server refers to the resource utilization of the server” monitored by load balancing module 210. VM migration module 104 can determine that the VM is to be migrated from the source server 202 … when load balancing module 210 communicates to the VM migration module 104 that the load of the source server 202 is below a second threshold.” This indicates that “all VMs hosted on the source server 202 may be migrated to other servers … without any significant performance overhead to the other servers.” Then the source server 202 “can be deployed in a low power mode, such as an off mode or a sleep mode.” Id. at ¶ 51. Claim 5 Nidugala discloses wherein determining the migration plan comprises: identifying multiple VMs on the first node that satisfy the migration criteria . When the load of source server 202 “decreases below the second threshold, the VM migration module 103 migrates the VM from the source server 202.” Further, the VM migration module 103 can migrate the VM from the source server 202 “when the utilization of any of the resources drops below the second threshold.” Id. at ¶ 51. The owner of source server 202 “can provide instructions to the VM migration module 104 to migrate all the VMs,” and “provide instructions for migration of the VM” (instructions for migration → migration plan). Id. at ¶ 54. Nidugala discloses selecting the second node from the plurality of nodes based on the second node having available resources to accommodate the multiple VMs . The load balancing module 210 (i.e., VM balancing service), “communicates with the monitoring agent(s) 302 periodically to determine the load of he source servers 202, so that if the load breaches … the second threshold, the VM migration module 104 can be informed.” Id. at ¶ 51. Based on performance metrics for each particular server, the VM migration nodule “determines the servers that have the resources for usage by the VM.” The VM migration module 104 “utilizes compatibility information for each particular server … to determine whether the VM is compatible with the server or not.” Id. at ¶¶ 56-58. The method determines “suitability scores for the plurality of candidate servers” based on criteria, and a set of servers is shortlisted “having suitability score greater than a threshold.” The server “having a higher capacity utilization compares to the other servers is selected to be the destination server.” The VM “can then be migrated to the destination server” (source server to a destination server → first node to a second node). Id. at ¶ 66. Claims 9 and 12-13 Claims 9 and 12-13 are rejected utilizing the aforementioned rationale for Claims 1 and 4-5 ; the claims are directed to a system performing the method. Claims 17-18 Claims 17-18 are rejected utilizing the aforementioned rationale for Claims 1 and 4 ; the claims are directed to a medium storing instructions corresponding to the method. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Nidugala et al., U.S. PG-Publication No. 2017/0315838 A1, in view of Marr et al., U.S. PG-Publication No. 2014/0082165 A1. Claim 2 Marr discloses wherein analyzing the received utilization metrics for the plurality of VMs comprises: comparing, for each of the plurality of VMs, the received utilization metrics for the VM against expected utilization metrics for the VM based on specifications of the virtual machine . Marr discloses methods “for determining resource usage and operating metric profiles” from “”an instance of a virtual machine.” VM lifecycle processing comprises “a service provider” that “can observe and record resource consumption,” and “determine a virtual machine instance resource usage and operating metric profile based on processing resource consumption measurements and other operating metric information.” Marr, ¶¶ 13-14. Profile determination module 202 analyzes “operating data regarding operating metrics and resource usage by instances of … all virtual machine instances” (operating metrics and resource usage → utilization metrics) to “develop an operating profile of the computing resources utilized by the … group of virtual machine instances being profiled” (operating profile → expected utilization metrics based on specification of the virtual machine). Marr discloses identifying a VM as satisfying the migration criteria when the received utilization metrics for the VM deviate from the expected utilization metrics for the VM beyond a threshold amount . Management component 102 comprises migration module 206 that “may monitor the resource utilization of each executing virtual machine … and the host computing device 104 on which the virtual machine instance is executing.” Then, “[w]hen the resource utilization changes, the migration module 206 … may select an appropriate host computing device 104 on which to place the virtual machine instance.” Id. at ¶ 32. Management component 102 “can determine whether resource usage or an operating metric differs from an expected or desired amount.” For example., the method “can determine whether a change in resource usage exceeds a threshold .” A VM instance that “begins to utilize more of a computing resource than expected, based on its operating profile and the placement determined by the management component 102, may be transferred to a host computing device 104.” Id. at ¶ 59. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the VM migration method o f Nidugala to incorporate VM migration based on deviation from expected utilization as taught by Marr . One of ordinary skill in the art would be motivated to integrate VM migration based on deviation from expected utilization into Nidugala , with a reasonable expectation of success, in order to improve performance; after migration the new virtual machine instance “may execute more efficiently due to the available resources.” Marr, ¶ 32. Claim 10 Claim 10 is rejected utilizing the aforementioned rationale for Claim 2; the claim is directed to a system performing the method. Claim s 3 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Nidugala et al., U.S. PG-Publication No. 2017/0315838 A1, in view of Cortez et al., U.S. PG-Publication No. 2020/0117494 A1. Claim 3 Cortez discloses wherein analyzing the received utilization metrics for the plurality of VMs comprises: inputting the received utilization metrics for an individual VM into a pre-trained machine learning model . Cortez discloses “a low-impact live migration system … that minimizes unfavorable impacts caused by live-migrating virtual machines.” Based on the “predicted impact of live-migrating … the live-migration system can selectively identify one or more … virtual machines to live-migrate” and “initiate live-migration of the select services.” Cortez, ¶ 13. Figure 2 illustrates exemplary migration system comprising “a data collection engine 202, an impact prediction engine 204, and a migration engine 206.” Id. at ¶ 32. Data collection engine 202 “can identify usage characteristics for a virtual machine,” including “a classification of time periods for which usage of the virtual machine is heavy or light.” The engine 202 can “identify memory characteristics associated with memory access or utilization of memory on the server node by the virtual machine,” including “a type of memory access pattern” and “other characteristics associated with memory access or utilization of memory by the virtual machine” (virtual machine characteristics → utilization metrics). Id. at ¶¶ 35-38; See Also ¶ 49 (characteristics may include “size of a virtual machine, memory access patterns of the virtual machine … or any other virtual machine characteristics”). The impact prediction engine 204 includes “a model (e.g., machine learning model) trained to determine a predicted impact score based on a combination of different virtual machine characteristics” (impact prediction engine → pre-trained machine learning model). Id. at ¶ 41. The data collection engine 202 “can provide any number of virtual machine characteristics to the impact prediction engine 204” (i.e., received metrics into a machine learning model). Cortez discloses generating, by the pre-trained machine learning model, a migration score indicating a likelihood that the individual VM should be migrated to a new node based on the inputted utilization metrics . The impact prediction engine 203 includes “a resource utilization prediction engine 310,” that “may predict an impact score.” Id. at ¶ 51. Resource utilization prediction engine 310 “may generate an impact score based on memory access characteristics.” The prediction engine 204 “generates “a combined impact score reflective of a predicted impact of live-migrating the virtual machine associated with a corresponding set of virtual machine characteristics” (impact score reflective of migration impact → migration score indicating a likelihood that a VM should be migrated). Id. at ¶¶ 65-66. Cortez discloses identifying the individual VM as satisfying the migration criteria when the migration score exceeds a threshold value . In one embodiment, Cortez discloses “selectively identifying one or more virtual machine for live-migration based on determined impact scores and further in view of a threshold impact.” The system “may determine an impact threshold based on current allocation state of a node cluster or server node,” used to “trigger the decision to live-migrate the virtual machine(s).” Id. at ¶¶ 90-91. When the system “determines that the predicted impact is greater than the impact threshold, the low-impact live migration system 104 can perform an act 660 of initiating live-migration of the candidate virtual machine.” Id. at ¶ 99. Cortez disclose s wherein the pre-trained machine learning model is trained using historical utilization metrics for a plurality of VMs having the same configuration and node configuration as the individual VM . Cortez discloses that “an impact may vary based on a type of application, a size of virtual machine, or other characteristics of a virtual machine.” Id. at ¶ 26. Data collection engine 202 identifies characteristics including “memory access patterns” (i.e., historical utilization metrics), “type of processor implemented by the server node corresponding to the virtual machine” and “capabilities of the … associated server node” (i.e., node configuration), and “capabilities of the virtual machine” (i.e., VM configuration). Id. at ¶ 38. The impact prediction engine 204 includes a “model (e.g., machine learning model) trained to determine a predicted impact score on a combination of different virtual machine characteristics.” Id. at ¶ 41. The prediction engine “is trained to determine impact scores for virtual machine based on associated virtual machine characteristics.” Id. at ¶ 103. Accordingly, the prediction engine is trained using VM data including characteristics comprising historical utilization (i.e., memory access patterns), a node configuration (i.e., node capabilities and processor type), and a VM configuration (i.e., VM capabilities). Training a model from utilization data of VMs having the same associated characteristics is analogous to training a model from utilization data of VMs having the same configurations . It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the VM migration method o f Nidugala to incorporate the machine learning model used to predict VM migration impact as taught by Cortez . One of ordinary skill in the art would be motivated to integrate the machine learning model used to predict VM migration into Nidugala , with a reasonable expectation of success, in order to “minimize unfavorable impacts of live-migration and redistribute virtual machines access server nodes … in such a way to improve performance of the server nodes.” Cortez, ¶ 46. Claim 11 Claim 1 1 is rejected utilizing the aforementioned rationale for Claim 3 ; the claim is directed to a system performing the method. Claim s 6, 8, 14, 16, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Nidugala et al., U.S. PG-Publication No. 2017/0315838 A1, in view of Garrett, U.S. PG-Publication No. 2006/0085530 A1. Claim 6 Garrett discloses wherein nodes in the plurality of nodes are organized into clusters based on common hardware configurations, and wherein the migration criteria are specific to a cluster . Garrett discloses a method of monitoring resource and relocating resources “to redistribute workload on a network.” Garrett, ¶¶ 12. Physical nodes managing the resources are within a cluster, wherein “a cluster refers to one or more nodes that are grouped together to form a cluster” (i.e., nodes are organized into cluster). Id. at ¶ 23. The forming of resource group including one or more virtual machines “can be implemented on clusters having any type of configuration” (e.g., common hardware configuration). Id. at ¶ 28. In one embodiment, the “virtual machines have the potential have the potential to be dynamically relocated across physical host nodes in a cluster.” Id. at ¶ 29. A relocation policy is utilized “to determine destination nodes to relocate each of the virtual machines 335A-335C” (relocation policy → migration criteria). Id. at ¶ 40. In another embodiment, it is “desirable to configure a resource group to enable it to use physical nodes … outside the cluster to satisfy the availability requirements for a resource group ,” wherein the “resource group can be configured to include a relocation policy for at least one resource in the group that authorized the relocation of the resource to a different cluster” (relocation policy specific to resource group → migration criteria specific to cluster). Id. at ¶ 60. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the VM migration method o f Nidugala to incorporate the lightweight VM monitoring agents as taught by Garrett . One of ordinary skill in the art would be motivated to integrate lightweight VM monitoring agents into Nidugala , with a reasonable expectation of success, in order to improve performance by providing “automated response to failures and/or specified events,” wherein “affected resources can be relocated to functioning systems within the network.” Garrett, ¶ 3 . Claim 8 Nidugala discloses wherein the utilization metrics for the plurality of VMs are received from … from node agents executing on the nodes on which the plurality of V Ms are executing . Nidugala discloses that to “obtain the performance metrics … the resource manager module 208 communicates with a monitoring agent(s) 302 in the source server 202, which can include agents that obtain performance metrics (monitoring agents → node agents). Nidugala, ¶ 38. Nidugala does not expressly disclose wherein the utilization for the plurality of VMs are received from VM agents executing on at least some of the plurality of VMs . Garrett discloses wherein the utilization for the plurality of VMs are received from VM agents executing on at least some of the plurality of VMs . Garrett discloses methods that “allow for the monitoring of a virtual machine,” via agents that gather information from the virtual machine. In one embodiment, “information is gathered through the use of lightweight agents 355A-F within the virtual machines 330A-F ” (lightweight agents → VM agents) . Id. at ¶ 34; FIG. 3. The agents “sense and collect metrics about the virtual machines or applications therein, and these metrics can then be communications to agents 320A-C. The relocation, i.e. migration, of virtual machines to a different node 310A is “triggered by sensed metrics pertaining to application running with the virtual machines (sent from the lightweight agents 335A-335C to agents 320A.” Further, a “relocation policy may be utilized by the agents 320A-C to determine destination nodes to relocate each of the virtual machines 335A-335C.” Id. at ¶ 40. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the VM migration method o f Nidugala to incorporate the lightweight VM monitoring agents as taught by Garrett . One of ordinary skill in the art would be motivated to integrate lightweight VM monitoring agents into Nidugala , with a reasonable expectation of success, in order to improve performance by providing “automated response to failures and/or specified events,” wherein “affected resources can be relocated to functioning systems within the network.” Garrett, ¶ 3 . Claims 14 and 16 Claims 14 and 16 are rejected utilizing the aforementioned rationale for Claims 6 and 8 ; the claims are directed to a system performing the method. Claims 19-20 Claims 19-20 are rejected utilizing the aforementioned rationale for Claims 6 and 8 ; the claims are directed to a medium storing instructions corresponding to the method. Claim s 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Nidugala et al., U.S. PG-Publication No. 2017/0315838 A1, in view of Garrett, U.S. PG-Publication No. 2006/0085530 A1. Claim 7 Elyashev discloses wherein a first cluster contains nodes optimized for computationally intensive workloads, and wherein the migration criteria for the first cluster prioritizes CPU and memory utilization metrics . Elyashev discloses a “method and system for live migration of virtual machines that run on a host cluster including a plurality of hosts.” A host controller “selects a virtual machine from the existing virtual machines that run on the overloaded host” and “selects a target host from the host cluster as a destination for migrating the selected virtual machine.” Elyashev , ¶ 10. In one embodiment, “hosts that have CPU utilization exceeding or near the high CPU utilization border” and “hosts that have CPU utilization below the deactivation threshold” are “excluded from the selection, unless no other suitable hosts can be found” (i.e., criteria prioritizing CPU utilization). After a host is selected, a “VM manager 120 confirms that the selected host has sufficient memory to accommodate the virtual machine.” If the request memory size exceeds the host memory size, “the VM manager 120 finds another host,” and “may continue the selection … until a host having sufficient memory is found.” (i.e., criteria prioritizing memory utilization). Id. at ¶¶ 35-36; See Also ¶ 41 (after selecting target host, “load balancer confirms that the selected host has sufficient resources; e.g., CPU resources and memory resources to accommodate the virtual machine”). Further , in one embodiment “hosts to be considered as a destination for migration may be low utilization hosts, which have CPU utilization below a low CPU utilization border … continuously for more than a predetermined time period” (i.e., nodes optimized for computationally intensive workloads). Id. at ¶ 40. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the clustered VM migration method o f Nidugala-Garrett to incorporate prioritizing CPU and memory metrics as taught by Elyashev . One of ordinary skill in the art would be motivated to integrate prioritizing CPU and memory metrics into Elyashev , with a reasonable expectation of success, in order to improve performance by preventing “load imbalance” that “can cause performance degradation.” Elyashev, ¶ 3. Claim 15 Claim 1 5 is rejected utilizing the aforementioned rationale for Claim 7 ; the claim is directed to a system performing the method. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to FILLIN "Examiner name" \* MERGEFORMAT FRANK D MILLS whose telephone number is FILLIN "Phone number" \* MERGEFORMAT (571)270-3194 . The examiner can normally be reached FILLIN "Work Schedule?" \* MERGEFORMAT M-F 10-6 ET . 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, FILLIN "SPE Name?" \* MERGEFORMAT KEVIN YOUNG can be reached at FILLIN "SPE Phone?" \* MERGEFORMAT (571)270-3180 . 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. /FRANK D MILLS/ Primary Examiner, Art Unit 2194 March 25, 2026