CTNF 18/657,706 CTNF 101517 DETAILED ACTION 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. The Office Action is in response to claims filed 05/07/2024. Claims 1-20 are pending. Claim Objections Claim 15 recites the limitation "the computing" in the first line of the claim. Examiner believes “the computing” is a typo and that it should read “the computer.” For the purposes of compact prosecution, “the computing” will be interpreted as “the computer.” Appropriate correction is required. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, an abstract idea, and it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below. Step 1: Claims 1-8 are directed to a method and fall within the statutory class of process. Claims 9-14 are directed to a non-transitory computer-readable medium and fall within the statutory class of articles of manufacture. Claims 15-20 are directed to a computer and fall within the statutory class of machine. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes. Step 2A Prong 1: Claims 1, 9, and 15 : The limitation “determining that the dummy VM that has been migrated to the destination host computer is able to communicate with the target VM” is considered a mental process involving observing and forming a judgement. It is understood that this limitation is to be performed within a computer environment, however, it can also entirely be performed in the mind. Therefore, Yes , claims 1, 9, and 15 recite a judicial exception. Step 2A Prong 2 will evaluate whether the claims integrate the judicial exception into a practical application. Step 2A Prong 2: Claims 1, 9, and 15 : The judicial exception is not integrated into a practical application. Claims 1, 9 and 15 recites the following additional elements – “A method of migrating an executing virtual machine (VM) from a source host computer to a destination host computer, the method comprising,” “issuing a first instruction to the source host computer to instantiate a dummy VM having a plurality of network configurations that match a corresponding plurality of network configurations of a target VM, which is running on the source host computer and has been targeted for migration,” “issuing second instructions to the source and destination host computers to migrate the dummy VM from the source host computer to the destination host computer,” and “and in response to determining that the migrated dummy VM is able to communicate with the target VM, issuing third instructions to the source and destination host computers to migrate the target VM from the source host computer to the destination host computer.” These additional elements are insignificant extra-solution activity (MPEP § 2106.05(g)). Claim 9 additionally recites “A non-transitory computer-readable medium comprising instructions that are executable in a computer system, wherein the instructions when executed cause the computer system to carry out a method of migrating an executing virtual machine (VM) from a source host computer to a destination host computer,” and claim 15 recites “A computer of a cloud platform, the computing including a processor and memory, wherein the computer is configured to use the processor to execute instructions from the memory to.” These additional elements are considered generic computing components used as a means to apply an exception (MPEP § 2106.05(f)). These additional elements do not integrate the judicial exception into a practical application. Therefore, “Do the claims recite additional elements that integrate the judicial exception in a practical application?” No , these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. After having evaluated the inquiries set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 9, and 15 not only recite a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into practical application. Step 2B: Claims 1, 9, and 15 : The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above, the additional elements only amount to insignificant extra-solution activity and generic computing components used as a means to apply an exception. When reevaluating the additional elements, alone or in combination, no inventive concept that amounts to significantly more was found. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. Issuing instructions to the source and/or destination hosts is transmitting data over a network. Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No , these additional elements, alone or in combination, do not amount to significantly more than the judicial exception. Having concluded analysis with in the provided framework, claims 1, 9, and 15 do not recite eligible subject matter under 35 U.S.C. § 101. With regard to claims 2, 10, and 16 it recites “in response to receiving performance metrics of migrating the dummy VM, comparing the received performance metrics to specified metrics.” This limitation is considered a mental process because comparing performance metrics to specified metrics can be performed entirely in the mind. Therefore, the claims recite an abstract idea and fail Step 2A Prong 1. The claims additionally recite “wherein the third instructions are issued with parameters for migrating the target VM that are adjusted according to a result of comparing the received performance metrics to the specified metrics.” This limitation is insignificant extra-solution activity of data transmission (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. Issuing instruction is transmitting data over a network. Therefore, the claims fail Step 2B. Therefore claims 2, 10, and 16 do not recite patent eligible subject matter under 35 U.S.C. 101. With regard to claims 3 and 11 it recites “wherein the parameters issued with the third instructions include a limit on read or write operations performed on a virtual disk of the target VM during migration of the target VM.” This limitation further limits the insignificant extra-solution activity of claims 1 and 2 and 8 and 9 respectively and is also considered insignificant extra-solution activity of data transmission (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. Issuing instruction is transmitting data over a network. Therefore, the claims fail Step 2B. Therefore claims 3 and 11 do not recite patent eligible subject matter under 35 U.S.C. 101. With regard to claims 4 and 18 it recites “before migration of the target VM, performing a customized precheck task created based on a policy of a first cluster that includes the source host or of a second cluster that includes the destination host.” This limitation is considered a mental process because performing tasks based on a policy can be performed entirely in the mind. Therefore, the claims are directed to a judicial exception and fail Step 2A Prong 1. The claims do not include any additional elements that integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. When reevaluating the claim limitations, alone or in combination, no inventive concept that amounts to significantly more was found. Therefore, the claims fail Step 2B. Therefore claims 4 and 18 do not recite patent eligible subject matter under 35 U.S.C. 101. With regard to claims 5 and 19 it recites “before migration of the target VM, confirming that a virtual switch configured in the destination host computer is connected to a logical Layer 2 (L2) network of the target VM.” This limitation is considered insignificant extra-solution activity of data gathering (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. When reevaluating the insignificant extra- solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. Performing the confirming step is receiving data over a network. Therefore, the claims fail Step 2B. Therefore claims 5 and 19 do not recite patent eligible subject matter under 35 U.S.C. 101. With regard to claims 6, 12, and 20 it recites “before migration of the target VM, confirming that a cluster of host computers includes enough host computers to satisfy a specified storage policy for storing a virtual disk of the target VM, or that one of the host computers of the cluster has enough free storage space to satisfy the specified storage policy, the destination host computer being in the cluster.” This limitation is considered insignificant extra-solution activity of data gathering (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. Performing the confirming step is receiving data over a network. Therefore, the claims fail Step 2B. Therefore claims 6, 12, and 20 do not recite patent eligible subject matter under 35 U.S.C. 101. With regard to claims 7 and 13 it recites “wherein the corresponding plurality of network configurations of the target VM includes one of: (1) using either a static or dynamic internet protocol (IP) address, (2) a specified number of virtual network interface controllers (vNICs) to use, and (3) a maximum transmission unit (MTU) for network transactions.” This limitation is considered field of use/technological environment (MPEP § 2106.05(h)) because it limits what is included in the environment of the network configuration. It does not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. When reevaluating the additional elements, alone or in combination, no inventive concept that amounts to significantly more was found. Therefore, the claims fail Step 2B. Therefore claims 7 and 13 do not recite patent eligible subject matter under 35 U.S.C. 101. With regard to claims 8 and 14 it recites “wherein migrating the dummy VM from the source host computer to the destination host computer includes transmitting, from a first cluster of host computers to a second cluster of host computers, a first virtual disk of the dummy VM and memory contents of the dummy VM,” “and then storing the transmitted first virtual disk in storage of the second cluster and storing the transmitted memory contents of the dummy VM in memory of the destination host computer,” “and wherein migrating the target VM from the source host computer to the destination host computer includes transmitting, from the first cluster to the second cluster, a second virtual disk of the target VM and memory contents of the target VM,” and “and then storing the transmitted second virtual disk in the storage of the second cluster and storing the transmitted memory contents of the target VM in the memory of the destination host computer.” These limitations are considered insignificant extra-solution activities of data transmission and storage (MPEP § 2106.05(g)). The claims additionally recite ““the source host computer being in the first cluster, and the destination host computer being in the second cluster.” This limitation is considered field of use/technological environment (MPEP § 2106.05(h)) because it limits the environment of the source and destination host computer. These additional elements do not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” and “Storing and retrieving information in memory” is a well understood, routine, and conventional computer function. Therefore, the claims Step 2B. Therefore claims 8 and 14 do not recite patent eligible subject matter under 35 U.S.C. 101. With regard to claim 17 it recites “before migration of the target VM, perform a default precheck task that is specified to be performed for a plurality of migrations including the migration of the target VM.” This limitation is considered a mental process because performing tasks based on a policy can be performed entirely in the mind. Therefore, claim 17 is directed to a judicial exception and fails Step 2A Prong 1. Claim 17 does not include any additional elements that integrate the judicial exception into a practical application, so claim 17 fails Step 2A Prong 2. When reevaluating the claim limitations, alone or in combination, no inventive concept that amounts to significantly more was found. Therefore, claim 17 fails Step 2B. Therefore claim 17 does not recite patent eligible subject matter under 35 U.S.C. 101. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim (s) 1, 7, 9, 13, 15, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart et al. Pat. No. US 9495269 B1 (hereafter Hart) in view of Zlotnick et al. Pat. No. US 20200334061 A1 (hereafter Zlotnick) and further in view of Price et al. Pat. No. US 20180152263 A1 (hereafter Price) . With regard to claim 1, Hart teaches a method of migrating an executing virtual machine (VM) from a source host computer to a destination host computer, the method comprising (Col. 2 Lines 54-55 states “The present invention may be a system, a method, and/or a computer program product.” Col. 6 Lines 65-67 states “FIG. 3 is a diagram depicting an embodiment of a data processing environment with logical partitions migrated from one system to another system.” Col. 1 Lines 27-32 states “each partition or instance of the operating system can look and feel like a separate server or machine from the perspective of its users. These instances are commonly referred to as “virtual” or “virtualized” machines, and each partition may be referred to as a logical partition (LPAR).” Examiner’s Note: LPAR is a virtual machine ): issuing a first instruction to the source host computer to instantiate a dummy VM having a plurality of network configurations that match a corresponding plurality of network configurations of a target VM, which is running on the source host computer and has been targeted for migration (Col. 7 Lines 12-14 states “For one or more of a variety of reasons, LPAR 320 is being migrated from system 310 to system 312.” Col. 7 Lines 19-22 states “migration validation first creates a test copy of the virtual machine being migrated (LPAR 320) onto the same system (system 310). A new test LPAR 321 is created with a configuration that matches LPAR 320.” Examiner’s Note: LPAR 321 is the dummy VM. LPAR 320 is the target VM ); issuing second instructions to the source and destination host computers to migrate the dummy VM from the source host computer to the destination host computer (Col. 11 Lines 32-35 states “at step 450, the process performs a trial migration of the new instance (test LPAR 321) created in source system 310 to target system 312.”); and in response to determining that the migrated dummy VM is able to communicate with the target VM, issuing third instructions to the source and destination host computers to migrate the target VM from the source host computer to the destination host computer (Col. 11 Lines 45-47 states “If the trial migration was successful, then decision 470 branches to the ‘yes’ branch to perform the actual migration at step 475.” Col. 7 Lines 34-36 states “If the trial migration is successful, then the live instance of the virtual machine is migrated from LPAR 320 on source system 310 to LPAR 322 on target system 312.” Examiner’s Note: the instructions to migrate LPAR 320 are made in response to the step of determining if the trial migration was successful ). Although Hart Col. 11 Lines 44-45 teaches “The process then determines whether the trial migration was successful (decision 470),” Hart does not explicitly teach determining that the dummy VM can communicate with the target VM. Hart also does not explicitly teach the copy LPAR has network configurations corresponding to the source LPAR. However, in an analogous art, Zlotnick teaches issuing a first instruction to the source host computer to instantiate a dummy VM having a plurality of network configurations that match a corresponding plurality of network configurations of a target VM, which is running on the source host computer and has been targeted for migration (¶ [0025] states “Dummy virtual machines are examples of dedicated virtual machines that have the same network interfaces as the virtual machines they are replacing. Thus, these dummy virtual machines are connected to the same subnets with the same IP addresses as the original virtual machines at the source site.”). determining that the dummy VM that has been migrated to the destination host computer is able to communicate with the target VM (¶ [0054] states “a connection between the dummy virtual machines and the migrated virtual machines (or between the source site and the target site) is established 208. The connections may be from virtual machine to virtual machine, from source site to target site, or the like.”) and in response to determining that the migrated dummy VM is able to communicate with the target VM , issuing third instructions to the source and destination host computers to migrate the target VM from the source host computer to the destination host computer (¶ [0054] states “a connection between the dummy virtual machines and the migrated virtual machines (or between the source site and the target site) is established 208. The connections may be from virtual machine to virtual machine, from source site to target site, or the like.”). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine dummy virtual machine having same network interfaces, subnets, and IP addresses and a connection between dummy and migrated virtual machines of Zlotnick with the test virtual machine and trial migration process of Hart. A person having ordinary skill in the art would have been motivated to make this combination because “Embodiments of the invention provide an automated solution that will simplify disaster recovery of discrete virtual machines from one site to another site at least for disaster recovery testing and for partial failover. This solution will enable organizations to gradually and seamlessly test disaster recovery readiness of multi-VM applications in a quick and a cost-efficient manner and will help enterprises save on disaster recovery costs and reduce the risk of failure when performing disaster recovery to the cloud” (¶ [0060]). Hart and Zlotnick do not explicitly teach determining if the dummy VM can communicate with the target VM. However, in analogous art, Price teaches determining that the dummy VM that has been migrated to the destination host computer is able to communicate with the target VM (¶ [0025] states “configurable traffic generator 230 in VM 125 autonomously begins generating and transmitting packets (e.g., pings) to test connections with other VMs for each category of traffic at the indicated rates.” Examiner’s Note: VMs test connection with other VMs by using packets such as pings ). and in response to determining that the migrated dummy VM is able to communicate with the target VM , issuing third instructions to the source and destination host computers to migrate the target VM from the source host computer to the destination host computer (¶ [0025] states “configurable traffic generator 230 in VM 125 autonomously begins generating and transmitting packets (e.g., pings) to test connections with other VMs for each category of traffic at the indicated rates.” Examiner’s Note: VMs test connection with other VMs by using packets such as pings ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the connection testing with packets of Price with the test virtual machine and trial migration of Hart and the dummy VM matching network configuration the migrated VM of Zlotnick. As a result, packets are exchanged between the source LPAR and test copy LPAR after the copy LPAR has migrated to test network connections. A person having ordinary skill in the art would have been motivated to make this combination to efficiently test endpoints in a logical network (¶ [0009] states “However, as the size of the logical network grows, it may not be feasible for the network controller to test these connections individually.” ¶ [0010] states “embodiments described herein relate to techniques for testing connections between endpoints in a logical network that resolve these issues, for example, by conducting the testing in a distributed manner.”). With regard to claim 7, Hart, Zlotnick, and Price teach the method of claim 1 . Hart, Zlotnick, and Price do not explicitly teach details of corresponding network configurations of the target VM. However, in an analogous art, Zlotnick teaches wherein the corresponding plurality of network configurations of the target VM includes one of: (1) using either a static or dynamic internet protocol (IP) address (¶ [0025] states “these dummy virtual machines are connected to the same subnets with the same IP addresses as the original virtual machines at the source site.”), (2) a specified number of virtual network interface controllers (vNICs) to use, and (3) a maximum transmission unit (MTU) for network transactions. With regard to claim 9, Hart teaches a non-transitory computer-readable medium comprising instructions that are executable in a computer system, wherein the instructions when executed cause the computer system to carry out a method of migrating an executing virtual machine (VM) from a source host computer to a destination host computer, and wherein the method comprises (Col. 2 Lines 54-59 states “The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.”): issuing a first instruction to the source host computer to instantiate a dummy VM having a plurality of network configurations that match a corresponding plurality of network configurations of a target VM, which is running on the source host computer and has been targeted for migration (Col. 7 Lines 12-14 states “For one or more of a variety of reasons, LPAR 320 is being migrated from system 310 to system 312.” Col. 7 Lines 19-22 states “migration validation first creates a test copy of the virtual machine being migrated (LPAR 320) onto the same system (system 310). A new test LPAR 321 is created with a configuration that matches LPAR 320.” Examiner’s Note: LPAR 321 is the dummy VM. LPAR 320 is the target VM ); issuing second instructions to the source and destination host computers to migrate the dummy VM from the source host computer to the destination host computer (Col. 11 Lines 32-35 states “at step 450, the process performs a trial migration of the new instance (test LPAR 321) created in source system 310 to target system 312.”); and in response to determining that the migrated dummy VM is able to communicate with the target VM, issuing third instructions to the source and destination host computers to migrate the target VM from the source host computer to the destination host computer (Col. 11 Lines 45-47 states “If the trial migration was successful, then decision 470 branches to the ‘yes’ branch to perform the actual migration at step 475.” Col. 7 Lines 34-36 states “If the trial migration is successful, then the live instance of the virtual machine is migrated from LPAR 320 on source system 310 to LPAR 322 on target system 312.” Examiner’s Note: the instructions to migrate LPAR 320 are made in response to the step of determining if the trial migration was successful ). Although Hart Col. 11 Lines 44-45 teaches “The process then determines whether the trial migration was successful (decision 470),” Hart does not explicitly teach determining that the dummy VM can communicate with the target VM. Hart also does not explicitly teach the copy LPAR has network configurations corresponding to the source LPAR. However, in an analogous art, Zlotnick teaches issuing a first instruction to the source host computer to instantiate a dummy VM having a plurality of network configurations that match a corresponding plurality of network configurations of a target VM, which is running on the source host computer and has been targeted for migration (¶ [0025] states “Dummy virtual machines are examples of dedicated virtual machines that have the same network interfaces as the virtual machines they are replacing. Thus, these dummy virtual machines are connected to the same subnets with the same IP addresses as the original virtual machines at the source site.”). determining that the dummy VM that has been migrated to the destination host computer is able to communicate with the target VM (¶ [0054] states “a connection between the dummy virtual machines and the migrated virtual machines (or between the source site and the target site) is established 208. The connections may be from virtual machine to virtual machine, from source site to target site, or the like.”) and in response to determining that the migrated dummy VM is able to communicate with the target VM , issuing third instructions to the source and destination host computers to migrate the target VM from the source host computer to the destination host computer (¶ [0054] states “a connection between the dummy virtual machines and the migrated virtual machines (or between the source site and the target site) is established 208. The connections may be from virtual machine to virtual machine, from source site to target site, or the like.”). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine dummy virtual machine having same network interfaces, subnets, and IP addresses and a connection between dummy and migrated virtual machines of Zlotnick with the test virtual machine and trial migration process of Hart. A person having ordinary skill in the art would have been motivated to make this combination because “Embodiments of the invention provide an automated solution that will simplify disaster recovery of discrete virtual machines from one site to another site at least for disaster recovery testing and for partial failover. This solution will enable organizations to gradually and seamlessly test disaster recovery readiness of multi-VM applications in a quick and a cost-efficient manner and will help enterprises save on disaster recovery costs and reduce the risk of failure when performing disaster recovery to the cloud” (¶ [0060]). Hart and Zlotnick do not explicitly teach determining if the dummy VM can communicate with the target VM. However, in analogous art, Price teaches determining that the dummy VM that has been migrated to the destination host computer is able to communicate with the target VM (¶ [0025] states “configurable traffic generator 230 in VM 125 autonomously begins generating and transmitting packets (e.g., pings) to test connections with other VMs for each category of traffic at the indicated rates.” Examiner’s Note: VMs test connection with other VMs by using packets such as pings ). and in response to determining that the migrated dummy VM is able to communicate with the target VM , issuing third instructions to the source and destination host computers to migrate the target VM from the source host computer to the destination host computer (¶ [0025] states “configurable traffic generator 230 in VM 125 autonomously begins generating and transmitting packets (e.g., pings) to test connections with other VMs for each category of traffic at the indicated rates.” Examiner’s Note: VMs test connection with other VMs by using packets such as pings ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the connection testing with packets of Price with the test virtual machine and trial migration of Hart and the dummy VM matching network configuration the migrated VM of Zlotnick. As a result, packets are exchanged between the source LPAR and test copy LPAR after the copy LPAR has migrated to test network connections. A person having ordinary skill in the art would have been motivated to make this combination to efficiently test endpoints in a logical network (¶ [0009] states “However, as the size of the logical network grows, it may not be feasible for the network controller to test these connections individually.” ¶ [0010] states “embodiments described herein relate to techniques for testing connections between endpoints in a logical network that resolve these issues, for example, by conducting the testing in a distributed manner.”). With regard to claim 13, Hart, Zlotnick, and Price teach the non-transitory computer-readable medium of claim 9 . Zlotnick additionally teaches wherein the corresponding plurality of network configurations of the target VM includes one of: (1) using either a static or dynamic internet protocol (IP) address (¶ [0025] states “these dummy virtual machines are connected to the same subnets with the same IP addresses as the original virtual machines at the source site.”), (2) a specified number of virtual network interface controllers (vNICs) to use, and (3) a maximum transmission unit (MTU) for network transactions. With regard to claim 15, Hart teaches a computer of a cloud platform, the computing including a processor and memory, wherein the computer is configured to use the processor to execute instructions from the memory to (Col. 4 Lines 1-6 states “These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer”. Col. 2 Line 67 through Col. 3 Line 4 states “A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM),”): issue a first instruction to a source host computer to instantiate a dummy VM having a plurality of network configurations that match a corresponding plurality of network configurations of a target VM, which is running on the source host computer and has been targeted for migration (Col. 7 Lines 12-14 states “For one or more of a variety of reasons, LPAR 320 is being migrated from system 310 to system 312.” Col. 7 Lines 19-22 states “migration validation first creates a test copy of the virtual machine being migrated (LPAR 320) onto the same system (system 310). A new test LPAR 321 is created with a configuration that matches LPAR 320.” Examiner’s Note: LPAR 321 is the dummy VM. LPAR 320 is the target VM ); issue second instructions to the source host computer and a destination host computer to migrate the dummy VM from the source host computer to the destination host computer (Col. 11 Lines 32-35 states “at step 450, the process performs a trial migration of the new instance (test LPAR 321) created in source system 310 to target system 312.”); and in response to determining that the migrated dummy VM is able to communicate with the target VM, issue third instructions to the source and destination host computers to migrate the target VM from the source host computer to the destination host computer (Col. 11 Lines 45-47 states “If the trial migration was successful, then decision 470 branches to the ‘yes’ branch to perform the actual migration at step 475.” Col. 7 Lines 34-36 states “If the trial migration is successful, then the live instance of the virtual machine is migrated from LPAR 320 on source system 310 to LPAR 322 on target system 312.” Examiner’s Note: the instructions to migrate LPAR 320 are made in response to the step of determining if the trial migration was successful ). Although Hart Col. 11 Lines 44-45 teaches “The process then determines whether the trial migration was successful (decision 470),” Hart does not explicitly teach determining that the dummy VM can communicate with the target VM. Hart also does not explicitly teach the copy LPAR has network configurations corresponding to the source LPAR. However, in an analogous art, Zlotnick teaches issue a first instruction to a source host computer to instantiate a dummy VM having a plurality of network configurations that match a corresponding plurality of network configurations of a target VM, which is running on the source host computer and has been targeted for migration (¶ [0025] states “Dummy virtual machines are examples of dedicated virtual machines that have the same network interfaces as the virtual machines they are replacing. Thus, these dummy virtual machines are connected to the same subnets with the same IP addresses as the original virtual machines at the source site.”); determine that the dummy VM that has been migrated to the destination host computer is able to communicate with the target VM (¶ [0054] states “a connection between the dummy virtual machines and the migrated virtual machines (or between the source site and the target site) is established 208. The connections may be from virtual machine to virtual machine, from source site to target site, or the like.”); and in response to determining that the migrated dummy VM is able to communicate with the target VM , issue third instructions to the source and destination host computers to migrate the target VM from the source host computer to the destination host computer (¶ [0054] states “a connection between the dummy virtual machines and the migrated virtual machines (or between the source site and the target site) is established 208. The connections may be from virtual machine to virtual machine, from source site to target site, or the like.”). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine dummy virtual machine having same network interfaces, subnets, and IP addresses and a connection between dummy and migrated virtual machines of Zlotnick with the test virtual machine and trial migration process of Hart. A person having ordinary skill in the art would have been motivated to make this combination because “Embodiments of the invention provide an automated solution that will simplify disaster recovery of discrete virtual machines from one site to another site at least for disaster recovery testing and for partial failover. This solution will enable organizations to gradually and seamlessly test disaster recovery readiness of multi-VM applications in a quick and a cost-efficient manner and will help enterprises save on disaster recovery costs and reduce the risk of failure when performing disaster recovery to the cloud” (¶ [0060]). Hart and Zlotnick do not explicitly teach determining if the dummy VM can communicate with the target VM. However, in analogous art, Price teaches determine that the dummy VM that has been migrated to the destination host computer is able to communicate with the target VM (¶ [0025] states “configurable traffic generator 230 in VM 125 autonomously begins generating and transmitting packets (e.g., pings) to test connections with other VMs for each category of traffic at the indicated rates.” Examiner’s Note: VMs test connection with other VMs by using packets such as pings ); and in response to determining that the migrated dummy VM is able to communicate with the target VM , issue third instructions to the source and destination host computers to migrate the target VM from the source host computer to the destination host computer (¶ [0025] states “configurable traffic generator 230 in VM 125 autonomously begins generating and transmitting packets (e.g., pings) to test connections with other VMs for each category of traffic at the indicated rates.” Examiner’s Note: VMs test connection with other VMs by using packets such as pings ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the connection testing with packets of Price with the test virtual machine and trial migration of Hart and the dummy VM matching network configuration the migrated VM of Zlotnick. As a result, packets are exchanged between the source LPAR and test copy LPAR after the copy LPAR has migrated to test network connections. A person having ordinary skill in the art would have been motivated to make this combination to efficiently test endpoints in a logical network (¶ [0009] states “However, as the size of the logical network grows, it may not be feasible for the network controller to test these connections individually.” ¶ [0010] states “embodiments described herein relate to techniques for testing connections between endpoints in a logical network that resolve these issues, for example, by conducting the testing in a distributed manner.”). With regards to claim 17, Hart, Zlotnick, and Price teach the computer of claim 15. Hart additionally teaches further configured to: before migration of the target VM, perform a default precheck task that is specified to be performed for a plurality of migrations including the migration of the target VM (Col. 9 Lines 45-47 states “Allocation module 370 is used to select and/or set a desired allocation of resources for partition mobility operations.” Col. 9 Lines 49-51 states “the allocation setting may be selected to apply to each partition for a mobility operation covering multiple partitions.” Col. 1 Lines 27-32 states “each partition or instance of the operating system can look and feel like a separate server or machine from the perspective of its users. These instances are commonly referred to as “virtual” or “virtualized” machines, and each partition may be referred to as a logical partition (LPAR).” Examiner’s note selecting or setting a desired allocation of resources for partition mobility operations is a default precheck task. Partitions are virtual machines ) . 07-21-aia AIA Claim (s) 2, 10, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of Zlotnick and Price, and further in view of Igelka et al. Pat. No. US 20220027182 A1 (hereafter Igelka) . With regard to claim 2, Hart, Zlotnick, and Price teach the method of claim 1 . Hart additionally teaches further comprising: in response to receiving performance metrics of migrating the dummy VM , comparing the received performance metrics to specified metrics, wherein the third instructions are issued with parameters for migrating the target VM that are adjusted according to a result of comparing the received performance metrics to the specified metrics (Col. 11 Lines 32-35 states “at step 450, the process performs a trial migration of the new instance (test LPAR 321) created in source system 310 to target system 312.” Col. 9 Lines 27-31 states “Embodiments of the present disclosure enable the flexible selection of memory resources and CPU thread configuration (e.g., number and running time) in a way to fit concurrency versus performance needs for the partition mobility operations.” Col. 10 Lines 21-24 states “It should be understood that other types of resources and/or resource attributes may be correspondingly set/allocated for the mobility operations to accommodate performance and/or concurrency requirements.” Examiner’s Note: performance or concurrency requirements/needs are specified metrics. Selection of memory resource and CPU thread configuration are parameters ). Hart, Zlotnick, and Price do not explicitly teach receiving performance metrics, comparing received performance metrics, and adjusting parameters. However, in an analogous art, Igelka teaches further comprising: in response to receiving performance metrics of migrating the dummy VM, comparing the received performance metrics to specified metrics, wherein the third instructions are issued with parameters for migrating the target VM that are adjusted according to a result of comparing the received performance metrics to the specified metrics (¶ [0027] states “can determine parameters associated with a migration event, monitor and determine the status of the migration event based on various metrics including those discussed above, and make adjustments to the migration process to meet customer needs (e.g., specific VMs must complete migration around the same time) and mitigate against non-convergence(s).” ¶ [0031] states “the system may also dynamically adjust parameters associated with a migration wave or event as part of migration processing,” “The system may then detect performance metrics such as for example disk size, disk rewrite rate, data transfer rate, data compressibility, etc.,” and “if the metrics indicate that the initial cut-over threshold will not result in a timely cut-over, e.g., to meet an end-user request or because of another event such as a data center maintenance event, the initial cut-over threshold may be adjusted or tuned.” ¶ [0009] states “Performance metrics may include one or more of snapshot data, compressibility of the computing resources to be migrated, available bandwidth on the network, CBT variance of each of the one or more virtual machines. Performance metrics may also comprise one or more of disk size, disk rewrite rate, cut-over threshold, snapshot duration, and network speed.” Examiner’s Note: customer needs and the timeliness of cut-over are specified metrics. The initial cut-over threshold that is based off of detected metrics is the performance metric that is compared to the specified metrics. The cut-over threshold is a parameter that is adjusted according to the comparison of initial cut-over threshold and timeliness of cut-over ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the monitoring of virtual machine migrations and adjusting of cut-over thresholds of Igelka with the memory resource and CPU thread allocation of Hart, the matching network configuration between dummy and migrated VM of Zlotnick, and the test of network connectivity of Price. As a result, performance metrics of the test LPAR of Hart is monitored during migration. The monitored metrics are used to adjust the migration parameters for the target VM. A person having ordinary skill in the art would have been motivated to make this combination because “By taking these factors into account to improve the timing of when to start taking snapshots and migrating each VM of a mass migration wave, the total amount of data that needs to transfer from the source to the destination can be reduced (since less snapshots are taken, and, e.g., disk rewrite rates are taken into account). This in turn, may shorten the time it takes to be ready for the cut-over operation” (¶ [0068]). With regard to claim 10, Hart, Zlotnick, and Price teach the non-transitory computer-readable medium of claim 9. Hart additionally teaches wherein the method further comprises: in response to receiving performance metrics of migrating the dummy VM, comparing the received performance metrics to specified metrics, wherein the third instructions are issued with parameters for migrating the target VM that are adjusted according to a result of comparing the received performance metrics to the specified metrics (Col. 11 Lines 32-35 states “at step 450, the process performs a trial migration of the new instance (test LPAR 321) created in source system 310 to target system 312.” Col. 9 Lines 27-31 states “Embodiments of the present disclosure enable the flexible selection of memory resources and CPU thread configuration (e.g., number and running time) in a way to fit concurrency versus performance needs for the partition mobility operations.” Col. 10 Lines 21-24 states “It should be understood that other types of resources and/or resource attributes may be correspondingly set/allocated for the mobility operations to accommodate performance and/or concurrency requirements.” Examiner’s Note: performance or concurrency requirements/needs are specified metrics. Selection of memory resource and CPU thread configuration are parameters ). Hart, Zlotnick, and Price do not explicitly teach receiving performance metrics, comparing received performance metrics, and adjusting parameters. However, in an analogous art, Igelka teaches wherein the method further comprises: in response to receiving performance metrics of migrating the dummy VM, comparing the received performance metrics to specified metrics, wherein the third instructions are issued with parameters for migrating the target VM that are adjusted according to a result of comparing the received performance metrics to the specified metrics (¶ [0027] states “can determine parameters associated with a migration event, monitor and determine the status of the migration event based on various metrics including those discussed above, and make adjustments to the migration process to meet customer needs (e.g., specific VMs must complete migration around the same time) and mitigate against non-convergence(s).” ¶ [0031] states “the system may also dynamically adjust parameters associated with a migration wave or event as part of migration processing,” “The system may then detect performance metrics such as for example disk size, disk rewrite rate, data transfer rate, data compressibility, etc.,” and “if the metrics indicate that the initial cut-over threshold will not result in a timely cut-over, e.g., to meet an end-user request or because of another event such as a data center maintenance event, the initial cut-over threshold may be adjusted or tuned.” ¶ [0009] states “Performance metrics may include one or more of snapshot data, compressibility of the computing resources to be migrated, available bandwidth on the network, CBT variance of each of the one or more virtual machines. Performance metrics may also comprise one or more of disk size, disk rewrite rate, cut-over threshold, snapshot duration, and network speed.” Examiner’s Note: customer needs and the timeliness of cut-over are specified metrics. The initial cut-over threshold that is based off of detected metrics is the performance metric that is compared to the specified metrics. The cut-over threshold is a parameter that is adjusted according to the comparison of initial cut-over threshold and timeliness of cut-over ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the monitoring of virtual machine migrations and adjusting of cut-over thresholds of Igelka with the memory resource and CPU thread allocation of Hart, the matching network configuration between dummy and migrated VM of Zlotnick, and the test of network connectivity of Price. As a result, performance metrics of the test LPAR of Hart is monitored during migration. The monitored metrics are used to adjust the migration parameters for the target VM. A person having ordinary skill in the art would have been motivated to make this combination because “By taking these factors into account to improve the timing of when to start taking snapshots and migrating each VM of a mass migration wave, the total amount of data that needs to transfer from the source to the destination can be reduced (since less snapshots are taken, and, e.g., disk rewrite rates are taken into account). This in turn, may shorten the time it takes to be ready for the cut-over operation” (¶ [0068]). With regard to claim 16, Hart, Zlotnick and Price teach the computer of claim 15. Hart additionally teaches further configured to: in response to receiving performance metrics of migrating the dummy VM, compare the received performance metrics to specified metrics, wherein the third instructions are issued with parameters for migrating the target VM that are adjusted according to a result of comparing the received performance metrics to the specified metrics (Col. 11 Lines 32-35 states “at step 450, the process performs a trial migration of the new instance (test LPAR 321) created in source system 310 to target system 312.” Col. 9 Lines 27-31 states “Embodiments of the present disclosure enable the flexible selection of memory resources and CPU thread configuration (e.g., number and running time) in a way to fit concurrency versus performance needs for the partition mobility operations.” Col. 10 Lines 21-24 states “It should be understood that other types of resources and/or resource attributes may be correspondingly set/allocated for the mobility operations to accommodate performance and/or concurrency requirements.” Examiner’s Note: performance or concurrency requirements/needs are specified metrics. Selection of memory resource and CPU thread configuration are parameters ). Hart, Zlotnick, and Price do not explicitly teach receiving performance metrics, comparing received performance metrics, and adjusting parameters. However, in an analogous art, Igelka teaches further configured to: in response to receiving performance metrics of migrating the dummy VM, compare the received performance metrics to specified metrics, wherein the third instructions are issued with parameters for migrating the target VM that are adjusted according to a result of comparing the received performance metrics to the specified metrics (¶ [0027] states “can determine parameters associated with a migration event, monitor and determine the status of the migration event based on various metrics including those discussed above, and make adjustments to the migration process to meet customer needs (e.g., specific VMs must complete migration around the same time) and mitigate against non-convergence(s).” ¶ [0031] states “the system may also dynamically adjust parameters associated with a migration wave or event as part of migration processing,” “The system may then detect performance metrics such as for example disk size, disk rewrite rate, data transfer rate, data compressibility, etc.,” and “if the metrics indicate that the initial cut-over threshold will not result in a timely cut-over, e.g., to meet an end-user request or because of another event such as a data center maintenance event, the initial cut-over threshold may be adjusted or tuned.” ¶ [0009] states “Performance metrics may include one or more of snapshot data, compressibility of the computing resources to be migrated, available bandwidth on the network, CBT variance of each of the one or more virtual machines. Performance metrics may also comprise one or more of disk size, disk rewrite rate, cut-over threshold, snapshot duration, and network speed.” Examiner’s Note: customer needs and the timeliness of cut-over are specified metrics. The initial cut-over threshold that is based off of detected metrics is the performance metric that is compared to the specified metrics. The cut-over threshold is a parameter that is adjusted according to the comparison of initial cut-over threshold and timeliness of cut-over ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the monitoring of virtual machine migrations and adjusting of cut-over thresholds of Igelka with the memory resource and CPU thread allocation of Hart, the matching network configuration between dummy and migrated VM of Zlotnick, and the test of network connectivity of Price. As a result, performance metrics of the test LPAR of Hart is monitored during migration. The monitored metrics are used to adjust the migration parameters for the target VM. A person having ordinary skill in the art would have been motivated to make this combination because “By taking these factors into account to improve the timing of when to start taking snapshots and migrating each VM of a mass migration wave, the total amount of data that needs to transfer from the source to the destination can be reduced (since less snapshots are taken, and, e.g., disk rewrite rates are taken into account). This in turn, may shorten the time it takes to be ready for the cut-over operation” (¶ [0068]) . 07-21-aia AIA Claim (s) 3 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of Zlotnick, Price, and Igelka, and further in view of Hogan “VSAN 6.2 Part 4 – IOPS limit for object” . With regard to claim 3, Hart, Zlotnick, Price, and Igelka teach the method of claim 2 . Hart additionally teaches wherein the parameters issued with the third instructions include a limit on read or write operations performed on a virtual disk of the target VM during migration of the target VM (Col. 9 Lines 27-31 states “Embodiments of the present disclosure enable the flexible selection of memory resources and CPU thread configuration (e.g., number and running time) in a way to fit concurrency versus performance needs for the partition mobility operations.” Col. 1 Lines 24-32 states “For example, the partitions can share the memory, the kernel, the processors, the hard drives, and/or other software, firmware, and/or hardware of the host. Thus, each partition or instance of the operating system can look and feel like a separate server or machine from the perspective of its users. These instances are commonly referred to as “virtual” or “virtualized” machines, and each partition may be referred to as a logical partition (LPAR).” Examiner’s Note: selection of memory resource and CPU thread configuration are parameters that are also considered a limit. Since partitions share the hard drives of the host, partitions are analogous to virtual disks ). Hart, Zlotnick, Price, and Igelka do not explicitly teach a limit on read or write operations. However, in an analogous art, Hogan teaches wherein the parameters issued with the third instructions include a limit on read or write operations performed on a virtual disk of the target VM during migration of the target VM (Lines 3-8 states “Through a policy setting, a customer can set an IOPS limit on a per object basis (typically VMDK) which will guarantee that the object will not be able to exceed this amount of IOPS. This is very useful if you have a virtual machine that might be consuming more than its fair share of resources.” Lines 24-26 states “One thing to consider is that not only is read and write I/O counted towards the limit, but also any snapshot I/O that occurs against the VM/VMDK is added to the IOPS limit.”). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the IOPS limits of Hogan with the memory resource and CPU thread parameters of Hart, the matching network configuration between dummy and migrated VM of Zlotnick, and the test of network connectivity of Price. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of “[ensuring] that there are “guard rails” placed on this virtual machine so it doesn’t impact other VMs, or impact the overall performance of the VSAN datastore” (Lines 8-10). With regard to claim 11, Hart, Zlotnick, and Price teach the non-transitory computer-readable medium of claim 10 . Hart additionally teaches wherein the parameters issued with the third instructions include a limit on read or write operations performed on a virtual disk of the target VM during migration of the target VM (Col. 9 Lines 27-31 states “Embodiments of the present disclosure enable the flexible selection of memory resources and CPU thread configuration (e.g., number and running time) in a way to fit concurrency versus performance needs for the partition mobility operations.” Col. 1 Lines 24-32 states “For example, the partitions can share the memory, the kernel, the processors, the hard drives, and/or other software, firmware, and/or hardware of the host. Thus, each partition or instance of the operating system can look and feel like a separate server or machine from the perspective of its users. These instances are commonly referred to as “virtual” or “virtualized” machines, and each partition may be referred to as a logical partition (LPAR).” Examiner’s Note: selection of memory resource and CPU thread configuration are parameters that are also considered a limit. Since partitions share the hard drives of the host, partitions are analogous to virtual disks ). Hart, Zlotnick, Price, and Igelka do not explicitly teach a limit on read or write operations. However, in an analogous art, Hogan teaches wherein the parameters issued with the third instructions include a limit on read or write operations performed on a virtual disk of the target VM during migration of the target VM (Lines 3-8 states “Through a policy setting, a customer can set an IOPS limit on a per object basis (typically VMDK) which will guarantee that the object will not be able to exceed this amount of IOPS. This is very useful if you have a virtual machine that might be consuming more than its fair share of resources.” Lines 24-26 states “One thing to consider is that not only is read and write I/O counted towards the limit, but also any snapshot I/O that occurs against the VM/VMDK is added to the IOPS limit.”). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the IOPS limits of Hogan with the memory resource and CPU thread parameters of Hart, the matching network configuration between dummy and migrated VM of Zlotnick, and the test of network connectivity of Price. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of “[ensuring] that there are “guard rails” placed on this virtual machine so it doesn’t impact other VMs, or impact the overall performance of the VSAN datastore” (Lines 8-10) . 07-21-aia AIA Claim (s) 4, 6, 12, 18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of Zlotnick, Price, and further in view of Ekbote Pat. No. US 20190384625 A1 (hereafter Ekbote) and Chu et al. Pat. No. US 20210389991 A1 (hereafter Chu) . With regard to claim 4, Hart, Zlotnick, and Price teach the method of claim 1 . Hart additionally teaches further comprising: before migration of the target VM, performing a customized precheck task created based on a policy of a first cluster that includes the source host or of a second cluster that includes the destination host (Col. 10 Lines 62-66 states “interface 372 may be configured to enable a user/administrator to select particular memory and/or thread allocation settings for mobility operations, thereby enabling a customized resource allocation for mobility operations.” Examiner’s Note: a customized resource allocation for mobility operations is a customized precheck task ). Hart, Zlotnick, and Price do not explicitly teach a first cluster and a second cluster. However, in an analogous art, Ekbote teaches further comprising: before migration of the target VM, performing a customized precheck task created based on a policy of a first cluster that includes the source host or of a second cluster that includes the destination host (¶ [0002] states “A group of hardware computing platforms may be organized as a cluster to provide resources for VMs. In a data center, it is common to see hundreds, even thousands, of VMs running on multiple clusters of hosts.” ¶ [0021] states “As shown, cross-site computing system 100 includes a source data center 102S and a destination computing system 102D. In one embodiment, source and destination computing systems 102S and 102D may be virtualized computing systems” and “discussed herein primarily with respect to a VM transfer from data center 102S to data center 102D.” See FIG. 1A. Examiner’s Note: source data center 102S represents a first cluster that includes the source host computer and destination data center 102D represents a second cluster that includes the destination host computer ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine source and destination clusters of Ekbote with the virtual machine migration using a test copy of Hart, the matching network configurations of dummy and migrated VMs of Zlotnick, and the testing of network connections between virtual machines of Price. As a result, the hosts in the virtual machine migration of Hart are located in data centers that represent clusters. A person having ordinary skill in the art would have been motivated to make this combination “to provide resources for VMs” (¶ [0002]). Additionally, by having the environment of data centers and clusters, “A particular path can then be selected for a VM transfer based on the stored information before initiating the transfer, thereby improving usage of resources and increasing the likelihood of the VM transfer's success” (¶ [0107]). Hart, Zlotnick, Price, and Ekbote do not explicitly teach a precheck task created based on a policy of a cluster. However, in an analogous art, Chu teaches further comprising: before migration of the target VM, performing a customized precheck task created based on a policy of a first cluster that includes the source host or of a second cluster that includes the destination host (¶ [0036] states “there is a possibility that the actual resource requirement for a cluster may be much less than the FTT number would suggest, and so embodiments of this disclosure may make use of the idle resources for upgrades.” ¶ [0037] states “a pre-check procedure may measure the minimum required resources according to hardware performance (e.g., including computing, memory, disk capacity, and software platform condition). A user (e.g., an administrator) may define the required workload threshold (such as 20% redundancy, 50% resource availability, etc.).” ¶ [0038] states “The upgrade pre-check procedure may then take into consideration the minimum required resources and redundancy, as well as the user-defined threshold.” Examiner’s Note: the pre-check procedure is the precheck task. The user defined workload thresholds are the policy of the cluster ) It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the pre-check procedure based on user defined thresholds of Chu with the resource allocation precheck task before migration of Hart, the matching network configurations of dummy and migrated VMs of Zlotnick, the testing of network connections between virtual machines of Price, and the cluster environment of Ekbote. A person having ordinary skill in the art would have been motivated to make this combination to “reduce upgrade time to a large extent by making multiple hosts upgrade in parallel without causing data loss or service disruption, by providing a method to utilize idle resources” (¶ [0035]). Performing a precheck task to ensure there is no data loss or service disruption is an improvement to the combination of Hart, Zlotnick, Price, and Ekbote. With regard to claim 6, Hart, Zlotnick, and Price teach the method of claim 1 . To reestablish the teaching, Hart teaches a virtual disk of the target VM (Col. 1 Lines 24-32 states “For example, the partitions can share the memory, the kernel, the processors, the hard drives, and/or other software, firmware, and/or hardware of the host. Thus, each partition or instance of the operating system can look and feel like a separate server or machine from the perspective of its users. These instances are commonly referred to as “virtual” or “virtualized” machines, and each partition may be referred to as a logical partition (LPAR).” Examiner’s Note: since partitions share hard drives, partitions include a virtual disk ). Hart, Zlotnick, and Price do not explicitly teach confirming if a host computer of the cluster has enough free storage space to satisfy the specified storage policy. However, in an analogous art, Ekbote teaches before migration of the target VM, confirming that a cluster of host computers includes enough host computers to satisfy a specified storage policy for storing a virtual disk of the target VM, or that one of the host computers of the cluster has enough free storage space to satisfy the specified storage policy, the destination host computer being in the cluster (¶ [0043] states “source virtualization manager 132S may determine a destination host 106D and accompanying destination storage unit 104D based on, e.g., resource usage statuses of the various destination hosts 106D and destination storage units 104D” and “Destination host 106D resource usage statuses may include CPU 108 load, available memory 110, available local storage 114, accessible destination storage units 104D, and the like, similar to source hosts 106S. Destination storage unit 104D resource usage statuses may include available storage and current I/O load.” ¶ [0002] states “A group of hardware computing platforms may be organized as a cluster to provide resources for VMs. In a data center, it is common to see hundreds, even thousands, of VMs running on multiple clusters of hosts.” ¶ [0021] states “As shown, cross-site computing system 100 includes a source data center 102S and a destination computing system 102D. In one embodiment, source and destination computing systems 102S and 102D may be virtualized computing systems” and “discussed herein primarily with respect to a VM transfer from data center 102S to data center 102D.” Examiner’s Note: the destination data center includes at least one cluster that has the destination host computer ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the host and storage unit selection process and clusters of Ekbote with the trial migration process of Hart, the matching networking settings between dummy and migrated VM of Zlotnick, and the testing of network connectivity between VMs of Price. A person having ordinary skill in the art would have been motivated to make this combination because selecting a suitable host and storage unit improves resource usage and likelihood of VM transfer success (¶ [0107] states “A particular path can then be selected for a VM transfer based on the stored information before initiating the transfer, thereby improving usage of resources and increasing the likelihood of the VM transfer's success”). Hart, Zlotnick, Price, and Ekbote do not explicitly state confirming that cluster has enough hosts to satisfy a specified storage policy or confirming one of the host computers of the cluster has enough free storage space to satisfy the specified storage policy. However, in an analogous art, Chu teaches before migration of the target VM, confirming that a cluster of host computers includes enough host computers to satisfy a specified storage policy for storing a virtual disk of the target VM, or that one of the host computers of the cluster has enough free storage space to satisfy the specified storage policy, the destination host computer being in the cluster (¶ [0037] states “a pre-check procedure may measure the minimum required resources according to hardware performance (e.g., including computing, memory, disk capacity, and software platform condition). A user (e.g., an administrator) may define the required workload threshold (such as 20% redundancy, 50% resource availability, etc.).” ¶ [0039] states “the minimum required number of hosts in the cluster may be reserved, and the rest of the hosts may safely be removed from the cluster.” ¶ [0053] states “Hosts that still need to be upgraded can be removed from the cluster as long as there are enough hosts remaining in the cluster to satisfy the requirements from the pre-check procedure.” Examiner’s Note: the pre-check procedure ensures there are enough host computers to satisfy the user-defined workload thresholds. The user defined-workload thresholds are the specified storage policy. Disk capacity and availability are examples of user-defined thresholds ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the pre-check task of verifying that there are enough hosts to satisfy the workload threshold and enough disk capacity and availability of Chu with the partitions and trial migration process of Hart, the premigration task of verifying enough storage space in destination host and destination storage unit and the cluster environment of Ekbote, the matching networking settings between dummy and migrated VM of Zlotnick, and the testing of network connectivity between VMs of Price. As a result, before the migration of LPAR 320 of Hart, the combination confirms that there are enough hosts or enough storage space to meet the workload thresholds of Chu. The hosts are in the cluster environment of Ekbote. A person having ordinary skill in the art would have been motivated to make this combination to “reduce upgrade time to a large extent by making multiple hosts upgrade in parallel without causing data loss or service disruption, by providing a method to utilize idle resources” (¶ [0035]). Performing a precheck task to ensure there is no data loss or service disruption is an improvement to the combination of Hart, Zlotnick, Price, and Ekbote. With regard to claim 12, Hart, Zlotnick, and Price teach the non-transitory computer-readable medium of claim 9 . To reestablish the teaching, Hart teaches a virtual disk of the target VM (Col. 1 Lines 24-32 states “For example, the partitions can share the memory, the kernel, the processors, the hard drives, and/or other software, firmware, and/or hardware of the host. Thus, each partition or instance of the operating system can look and feel like a separate server or machine from the perspective of its users. These instances are commonly referred to as “virtual” or “virtualized” machines, and each partition may be referred to as a logical partition (LPAR).” Examiner’s Note: since partitions share hard drives, partitions include a virtual disk ). Hart, Zlotnick, and Price do not explicitly teach confirming if a host computer of the cluster has enough free storage space to satisfy the specified storage policy. However, in an analogous art, Ekbote teaches wherein the method further comprises: before migration of the target VM, confirming that a cluster of host computers includes enough host computers to satisfy a specified storage policy for storing a virtual disk of the target VM, or that one of the host computers of the cluster has enough free storage space to satisfy the specified storage policy, the destination host computer being in the cluster (¶ [0043] states “source virtualization manager 132S may determine a destination host 106D and accompanying destination storage unit 104D based on, e.g., resource usage statuses of the various destination hosts 106D and destination storage units 104D” and “Destination host 106D resource usage statuses may include CPU 108 load, available memory 110, available local storage 114, accessible destination storage units 104D, and the like, similar to source hosts 106S. Destination storage unit 104D resource usage statuses may include available storage and current I/O load.” ¶ [0002] states “A group of hardware computing platforms may be organized as a cluster to provide resources for VMs. In a data center, it is common to see hundreds, even thousands, of VMs running on multiple clusters of hosts.” ¶ [0021] states “As shown, cross-site computing system 100 includes a source data center 102S and a destination computing system 102D. In one embodiment, source and destination computing systems 102S and 102D may be virtualized computing systems” and “discussed herein primarily with respect to a VM transfer from data center 102S to data center 102D.” Examiner’s Note: the destination data center includes at least one cluster that has the destination host computer ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the host and storage unit selection process and clusters of Ekbote with the trial migration process of Hart, the matching networking settings between dummy and migrated VM of Zlotnick, and the testing of network connectivity between VMs of Price. A person having ordinary skill in the art would have been motivated to make this combination because selecting a suitable host and storage unit improves resource usage and likelihood of VM transfer success (¶ [0107] states “A particular path can then be selected for a VM transfer based on the stored information before initiating the transfer, thereby improving usage of resources and increasing the likelihood of the VM transfer's success”). Hart, Zlotnick, Price, and Ekbote do not explicitly state confirming that cluster has enough hosts to satisfy a specified storage policy or confirming one of the host computers of the cluster has enough free storage space to satisfy the specified storage policy. However, in an analogous art, Chu teaches wherein the method further comprises: before migration of the target VM, confirming that a cluster of host computers includes enough host computers to satisfy a specified storage policy for storing a virtual disk of the target VM, or that one of the host computers of t he cluster has enough free storage space to satisfy the specified storage policy, the destination host computer being in the cluster (¶ [0037] states “a pre-check procedure may measure the minimum required resources according to hardware performance (e.g., including computing, memory, disk capacity, and software platform condition). A user (e.g., an administrator) may define the required workload threshold (such as 20% redundancy, 50% resource availability, etc.).” ¶ [0039] states “the minimum required number of hosts in the cluster may be reserved, and the rest of the hosts may safely be removed from the cluster.” ¶ [0053] states “Hosts that still need to be upgraded can be removed from the cluster as long as there are enough hosts remaining in the cluster to satisfy the requirements from the pre-check procedure.” Examiner’s Note: the pre-check procedure ensures there are enough host computers to satisfy the user-defined workload thresholds. The user defined-workload thresholds are the specified storage policy. Disk capacity and availability are examples of user-defined thresholds ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the pre-check task of verifying that there are enough hosts to satisfy the workload threshold and enough disk capacity and availability of Chu with the partitions and trial migration process of Hart, the premigration task of verifying enough storage space in destination host and destination storage unit and the cluster environment of Ekbote, the matching networking settings between dummy and migrated VM of Zlotnick, and the testing of network connectivity between VMs of Price. As a result, before the migration of LPAR 320 of Hart, the combination confirms that there are enough hosts or enough storage space to meet the workload thresholds of Chu. The hosts are in the cluster environment of Ekbote. A person having ordinary skill in the art would have been motivated to make this combination to “reduce upgrade time to a large extent by making multiple hosts upgrade in parallel without causing data loss or service disruption, by providing a method to utilize idle resources” (¶ [0035]). Performing a precheck task to ensure there is no data loss or service disruption is an improvement to the combination of Hart, Zlotnick, Price, and Ekbote. With regard to claim 18, Hart, Zlotnick, and Price teach the computer of claim 15 . Hart additionally teaches further configured to: before migration of the target VM, perform a customized precheck task created based on a policy of a first cluster that includes the source host or of a second cluster that includes the destination host (Col. 10 Lines 62-66 states “interface 372 may be configured to enable a user/administrator to select particular memory and/or thread allocation settings for mobility operations, thereby enabling a customized resource allocation for mobility operations.” Examiner’s Note: a customized resource allocation for mobility operations is a customized precheck task ). Hart, Zlotnick, and Price do not explicitly teach a first cluster and a second cluster. However, in an analogous art, Ekbote teaches further configured to: before migration of the target VM, perform a customized precheck task created based on a policy of a first cluster that includes the source host or of a second cluster that includes the destination host (¶ [0002] states “A group of hardware computing platforms may be organized as a cluster to provide resources for VMs. In a data center, it is common to see hundreds, even thousands, of VMs running on multiple clusters of hosts.” ¶ [0021] states “As shown, cross-site computing system 100 includes a source data center 102S and a destination computing system 102D. In one embodiment, source and destination computing systems 102S and 102D may be virtualized computing systems” and “discussed herein primarily with respect to a VM transfer from data center 102S to data center 102D.” See FIG. 1A. Examiner’s Note: source data center 102S represents a first cluster that includes the source host computer and destination data center 102D represents a second cluster that includes the destination host computer ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine source and destination clusters of Ekbote with the virtual machine migration using a test copy of Hart, the matching network configurations of dummy and migrated VMs of Zlotnick, and the testing of network connections between virtual machines of Price. As a result, the hosts in the virtual machine migration of Hart are located in data centers that represent clusters. A person having ordinary skill in the art would have been motivated to make this combination “to provide resources for VMs” (¶ [0002]). Additionally, by having the environment of data centers and clusters, “A particular path can then be selected for a VM transfer based on the stored information before initiating the transfer, thereby improving usage of resources and increasing the likelihood of the VM transfer's success” (¶ [0107]). Hart, Zlotnick, Price, and Ekbote do not explicitly teach a precheck task created based on a policy of a cluster. However, in an analogous art, Chu teaches further configured to: before migration of the target VM, perform a customized precheck task created based on a policy of a first cluster that includes the source host or of a second cluster that includes the destination host (¶ [0036] states “there is a possibility that the actual resource requirement for a cluster may be much less than the FTT number would suggest, and so embodiments of this disclosure may make use of the idle resources for upgrades.” ¶ [0037] states “a pre-check procedure may measure the minimum required resources according to hardware performance (e.g., including computing, memory, disk capacity, and software platform condition). A user (e.g., an administrator) may define the required workload threshold (such as 20% redundancy, 50% resource availability, etc.).” ¶ [0038] states “The upgrade pre-check procedure may then take into consideration the minimum required resources and redundancy, as well as the user-defined threshold.” Examiner’s Note: the pre-check procedure is the precheck task. The user defined workload thresholds are the policy of the cluster ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the pre-check procedure based on user defined thresholds of Chu with the resource allocation precheck task before migration of Hart, the matching network configurations of dummy and migrated VMs of Zlotnick, the testing of network connections between virtual machines of Price, and the cluster environment of Ekbote. A person having ordinary skill in the art would have been motivated to make this combination to “reduce upgrade time to a large extent by making multiple hosts upgrade in parallel without causing data loss or service disruption, by providing a method to utilize idle resources” (¶ [0035]). Performing a precheck task to ensure there is no data loss or service disruption is an improvement to the combination of Hart, Zlotnick, Price, and Ekbote. With regard to claim 20, Hart, Zlotnick, and Price teach the computer of claim 15 . To reestablish the teaching, Hart teaches a virtual disk of the target VM (Col. 1 Lines 24-32 states “For example, the partitions can share the memory, the kernel, the processors, the hard drives, and/or other software, firmware, and/or hardware of the host. Thus, each partition or instance of the operating system can look and feel like a separate server or machine from the perspective of its users. These instances are commonly referred to as “virtual” or “virtualized” machines, and each partition may be referred to as a logical partition (LPAR).” Examiner’s Note: since partitions share hard drives, partitions include a virtual disk ). Hart, Zlotnick, and Price do not explicitly teach confirming if a host computer of the cluster has enough free storage space to satisfy the specified storage policy. However, in an analogous art, Ekbote teaches further configured to: before migration of the target VM, confirm that a cluster of host computers includes enough host computers to satisfy a specified storage policy for storing a virtual disk of the target VM, or that one of the host computers of the cluster has enough free storage space to satisfy the specified storage policy, the destination host computer being in the cluster (¶ [0043] states “source virtualization manager 132S may determine a destination host 106D and accompanying destination storage unit 104D based on, e.g., resource usage statuses of the various destination hosts 106D and destination storage units 104D” and “Destination host 106D resource usage statuses may include CPU 108 load, available memory 110, available local storage 114, accessible destination storage units 104D, and the like, similar to source hosts 106S. Destination storage unit 104D resource usage statuses may include available storage and current I/O load.” ¶ [0002] states “A group of hardware computing platforms may be organized as a cluster to provide resources for VMs. In a data center, it is common to see hundreds, even thousands, of VMs running on multiple clusters of hosts.” ¶ [0021] states “As shown, cross-site computing system 100 includes a source data center 102S and a destination computing system 102D. In one embodiment, source and destination computing systems 102S and 102D may be virtualized computing systems” and “discussed herein primarily with respect to a VM transfer from data center 102S to data center 102D.” Examiner’s Note: the destination data center includes at least one cluster that has the destination host computer ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the host and storage unit selection process and clusters of Ekbote with the trial migration process of Hart, the matching networking settings between dummy and migrated VM of Zlotnick, and the testing of network connectivity between VMs of Price. A person having ordinary skill in the art would have been motivated to make this combination because selecting a suitable host and storage unit improves resource usage and likelihood of VM transfer success (¶ [0107] states “A particular path can then be selected for a VM transfer based on the stored information before initiating the transfer, thereby improving usage of resources and increasing the likelihood of the VM transfer's success”). Hart, Zlotnick, Price, and Ekbote do not explicitly state confirming one of the host computers of the cluster has enough free storage space to satisfy the specified storage policy. However, in an analogous art, Chu teaches further configured to: before migration of the target VM , confirm that a cluster of host computers includes enough host computers to satisfy a specified storage policy for storing a virtual disk of the target VM, or that one of the host computers of the cluster has enough free storage space to satisfy the specified storage policy, the destination host computer being in the cluster (¶ [0037] states “a pre-check procedure may measure the minimum required resources according to hardware performance (e.g., including computing, memory, disk capacity, and software platform condition). A user (e.g., an administrator) may define the required workload threshold (such as 20% redundancy, 50% resource availability, etc.).” ¶ [0039] states “the minimum required number of hosts in the cluster may be reserved, and the rest of the hosts may safely be removed from the cluster.” ¶ [0053] states “Hosts that still need to be upgraded can be removed from the cluster as long as there are enough hosts remaining in the cluster to satisfy the requirements from the pre-check procedure.” Examiner’s Note: the pre-check procedure ensures there are enough host computers to satisfy the user-defined workload thresholds. The user defined-workload thresholds are the specified storage policy. Disk capacity and availability are examples of user-defined thresholds ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the pre-check task of verifying that there are enough hosts to satisfy the workload threshold and enough disk capacity and availability of Chu with the partitions and trial migration process of Hart, the premigration task of verifying enough storage space in destination host and destination storage unit and the cluster environment of Ekbote, the matching networking settings between dummy and migrated VM of Zlotnick, and the testing of network connectivity between VMs of Price. As a result, before the migration of LPAR 320 of Hart, the combination confirms that there are enough hosts or enough storage space to meet the workload thresholds of Chu. The hosts are in the cluster environment of Ekbote. A person having ordinary skill in the art would have been motivated to make this combination to “reduce upgrade time to a large extent by making multiple hosts upgrade in parallel without causing data loss or service disruption, by providing a method to utilize idle resources” (¶ [0035]). Performing a precheck task to ensure there is no data loss or service disruption is an improvement to the combination of Hart, Zlotnick, Price, and Ekbote . 07-21-aia AIA Claim (s) 5 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of Zlotnick, Price, and further in view of Nipane et al. Pat. No. US 20160196158 A1 (hereafter Nipane) With regard to claim 5, Hart, Zlotnick, and Price teach the method of claim 1 . Hart additionally teaches before migration of the target VM, confirming that a virtual switch configured in the destination host computer is connected to a logical Layer 2 (L2) network of the target VM (Col. 7 Lines 14-19 states “The approach described herein, validates the migration before actually migrating the partition. In this manner, any problems with the migration are identified before the actual migration, thus avoiding problems associated with an unsuccessful migration.”). Price additionally teaches before migration of the target VM, confirming that a virtual switch configured in the destination host computer is connected to a logical Layer 2 (L2) network of the target VM (¶ [0025] states “configurable traffic generator 230 in VM 125 autonomously begins generating and transmitting packets (e.g., pings) to test connections with other VMs for each category of traffic at the indicated rates.” Examiner’s Note: the packets sent from VM 125 to other VMs tests if the virtual machines are connected ). Although Zlotnick teaches that a layer-2 VPN may be used to connect virtual machines (¶ [0028]) and Price teaches virtual switches (¶ [0013]), Hart, Zlotnick, and Price do not explicitly teach that a virtual switch configured in the destination host computer is connected to a logical Layer 2 network of the target VM. However, in an analogous art, Nipane teaches before migration of the target VM, confirming that a virtual switch configured in the destination host computer is connected to a logical Layer 2 (L2) network of the target VM (¶ [0029] states “Virtual switches 342.sub.1-2 in host servers 120.sub.1-2 are each a software implementation of a layer 2 switch, each including a plurality of virtual (i.e., software-implemented) ports, such as virtual ports 340, 341” and “Each VM may be logically connected to a virtual port on virtual switches 342.sub.1-2 which is, in turn, logically connected to physical NICs (e.g., PNICs 352.sub.1-2) in host server 110. Each PNIC is connected to a physical network and may communicate with other PNICs and the outside world via a router or a switch.” See FIG. 1 and 3. Examiner’s Note: since the VMs are connected to virtual ports that belong to virtual switches that are further connected by PNICs, the virtual switch in the destination computer is connected to a layer 2 network of the target VM ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the virtual switches that are connected to each other and to each host’s respective VMs with the trial migration process of Hart, the matching networking settings between dummy and migrated VM of Zlotnick, and the testing of network connectivity between VMs of Price. As a result, the network testing process of Price is applied within Nipane’s environment of a virtual switch connected to a logical layer 2 network of the target VM. A person having ordinary skill in the art would have been motivated to make this combination because “The VM can thus be migrated across distributed virtual switches or other virtual networks, and such migrations may be transparent to applications running in the VM” (¶ [0011]). The migration preserves the network connectivity of the VM (¶ [0032] states “Embodiments disclosed herein instantiate and reserve distributed virtual port(s) on a destination side, copy the network state data of the old distributed virtual port(s) to the reserved distributed virtual port(s), and connect the migrated VM to the reserved distributed virtual port(s), thereby providing network connectivity for the migrated VM in a manner transparent to applications running in the VM, including the guest operating system”). In other words, the portability of the VM is improved. With regard to claim 19, Hart, Zlotnick, and Price teach the computer of claim 15 . Hart additionally teaches further configured to: before migration of the target VM, confirm that a virtual switch configured in the destination host computer is connected to a logical Layer 2 (L2) network of the target VM (Col. 7 Lines 14-19 states “The approach described herein, validates the migration before actually migrating the partition. In this manner, any problems with the migration are identified before the actual migration, thus avoiding problems associated with an unsuccessful migration.”). Price additionally teaches further configured to: before migration of the target VM, confirm that a virtual switch configured in the destination host computer is connected to a logical Layer 2 (L2) network of the target VM (¶ [0025] states “configurable traffic generator 230 in VM 125 autonomously begins generating and transmitting packets (e.g., pings) to test connections with other VMs for each category of traffic at the indicated rates.” Examiner’s Note: the packets sent from VM 125 to other VMs tests if the virtual machines are connected ). Although Zlotnick teaches that a layer-2 VPN may be used to connect virtual machines (¶ [0028]) and Price teaches virtual switches (¶ [0013]), Hart, Zlotnick, and Price do not explicitly teach that a virtual switch configured in the destination host computer is connected to a logical Layer 2 network of the target VM. However, in an analogous art, Nipane teaches further configured to: before migration of the target VM, confirm that a virtual switch configured in the destination host computer is connected to a logical Layer 2 (L2) network of the target VM (¶ [0029] states “Virtual switches 342.sub.1-2 in host servers 120.sub.1-2 are each a software implementation of a layer 2 switch, each including a plurality of virtual (i.e., software-implemented) ports, such as virtual ports 340, 341” and “Each VM may be logically connected to a virtual port on virtual switches 342.sub.1-2 which is, in turn, logically connected to physical NICs (e.g., PNICs 352.sub.1-2) in host server 110. Each PNIC is connected to a physical network and may communicate with other PNICs and the outside world via a router or a switch.” See FIG. 1 and 3. Examiner’s Note: since the VMs are connected to virtual ports that belong to virtual switches that are further connected by PNICs, the virtual switch in the destination computer is connected to a layer 2 network of the target VM ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the virtual switches that are connected to each other and to each host’s respective VMs with the trial migration process of Hart, the matching networking settings between dummy and migrated VM of Zlotnick, and the testing of network connectivity between VMs of Price. As a result, the network testing process of Price is applied within Nipane’s environment of a virtual switch connected to a logical layer 2 network of the target VM. A person having ordinary skill in the art would have been motivated to make this combination because “The VM can thus be migrated across distributed virtual switches or other virtual networks, and such migrations may be transparent to applications running in the VM” (¶ [0011]). The migration preserves the network connectivity of the VM (¶ [0032] states “Embodiments disclosed herein instantiate and reserve distributed virtual port(s) on a destination side, copy the network state data of the old distributed virtual port(s) to the reserved distributed virtual port(s), and connect the migrated VM to the reserved distributed virtual port(s), thereby providing network connectivity for the migrated VM in a manner transparent to applications running in the VM, including the guest operating system”). In other words, the portability of the VM is improved . 07-21-aia AIA Claim (s) 8 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of Zlotnick, Price, and Ekbote . With regard to claim 8, Hart, Zlotnick, and Price teach the method of claim 1 . Hart additionally teaches wherein migrating the dummy VM from the source host computer to the destination host computer includes transmitting , from a first cluster of host computers to a second cluster of host computers, a first virtual disk of the dummy VM and memory contents of the dummy VM , and then storing the transmitted first virtual disk in storage of the second cluster and storing the transmitted memory contents of the dummy VM in memory of the destination host computer, the source host computer being in the first cluster, and the destination host computer being in the second cluster (Col. 1 Lines 24-32 states “For example, the partitions can share the memory, the kernel, the processors, the hard drives, and/or other software, firmware, and/or hardware of the host. Thus, each partition or instance of the operating system can look and feel like a separate server or machine from the perspective of its users. These instances are commonly referred to as “virtual” or “virtualized” machines, and each partition may be referred to as a logical partition (LPAR).” Col. 11 Lines 32-35 states “at step 450, the process performs a trial migration of the new instance (test LPAR 321) created in source system 310 to target system 312.” Col. 7 Lines 30-34 states “LPAR 322 is created matching the instance of LPAR 321 that was created on source system 310. A trial migration is performed of snapshot OS 325 running in LPAR 321 on system 310 to target LPAR 322 on system 312.” Examiner’s Note: LPARs share memory and hard disks of the host system, so LPARs have a virtual disk. When LPAR’s are migrated, they are replicating source LPAR state. Therefore, LPAR’s memory and virtual disks are transferred to the destination host computer ), and wherein migrating the target VM from the source host computer to the destination host computer includes transmitting, from the first cluster to the second cluster, a second virtual disk of the target VM and memory contents of the target VM, and then storing the transmitted second virtual disk in the storage of the second cluster and storing the transmitted memory contents of the target VM in the memory of the destination host computer (Col. 7 Lines 34-36 states “If the trial migration is successful, then the live instance of the virtual machine is migrated from LPAR 320 on source system 310 to LPAR 322 on target system 312.” Examiner’s Note: as explained above in the previous Examiner’s Note, the transfer of LPAR includes the transfer of a virtual disk and memory ). Hart, Zlotnick, and Price do not explicitly teach source and destination clusters of hosts. However, in an analogous art, Ekbote teaches wherein migrating the dummy VM from the source host computer to the destination host computer includes transmitting, from a first cluster of host computers to a second cluster of host computers, a first virtual disk of the dummy VM and memory contents of the dummy VM, and then storing the transmitted first virtual disk in storage of the second cluster and storing the transmitted memory contents of the dummy VM in memory of the destination host computer, the source host computer being in the first cluster, and the destination host computer being in the second cluster (¶ [0002] states “A group of hardware computing platforms may be organized as a cluster to provide resources for VMs. In a data center, it is common to see hundreds, even thousands, of VMs running on multiple clusters of hosts.” ¶ [0021] states “As shown, cross-site computing system 100 includes a source data center 102S and a destination computing system 102D. In one embodiment, source and destination computing systems 102S and 102D may be virtualized computing systems” and “discussed herein primarily with respect to a VM transfer from data center 102S to data center 102D.” See FIG. 1A. Examiner’s Note: source data center 102S represents a first cluster that includes the source host computer and destination data center 102D represents a second cluster that includes the destination host computer ), and wherein migrating the target VM from the source host computer to the destination host computer includes transmitting, from the first cluster to the second cluster, a second virtual disk of the target VM and memory contents of the target VM, and then storing the transmitted second virtual disk in the storage of the second cluster and storing the transmitted memory contents of the target VM in the memory of the destination host computer (¶ [0021] states “As shown, cross-site computing system 100 includes a source data center 102S and a destination computing system 102D. In one embodiment, source and destination computing systems 102S and 102D may be virtualized computing systems” and “discussed herein primarily with respect to a VM transfer from data center 102S to data center 102D.” See FIG. 1A. Examiner’s Note: source data center 102S has at least a first cluster that includes the source host computer and destination data center 102D has at least a second cluster that includes the destination host computer ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine source and destination clusters of Ekbote with the virtual machine migration using a test copy of Hart, the matching network configurations of dummy and migrated VMs of Zlotnick, and the testing of network connections between virtual machines of Price. As a result, the hosts in the virtual machine migration of Hart are located in data centers that represent clusters. A person having ordinary skill in the art would have been motivated to make this combination “to provide resources for VMs” (¶ [0002]). Additionally, by having the environment of data centers and clusters, “A particular path can then be selected for a VM transfer based on the stored information before initiating the transfer, thereby improving usage of resources and increasing the likelihood of the VM transfer's success” (¶ [0107]). With regard to claim 14, Hart, Zlotnick, and Price teach the non-transitory computer-readable medium of claim 9 . Hart additionally teaches wherein migrating the dummy VM from the source host computer to the destination host computer includes transmitting, from a first cluster of host computers to a second cluster of host computers, a first virtual disk of the dummy VM and memory contents of the dummy VM, and then storing the transmitted first virtual disk in storage of the second cluster and storing the transmitted memory contents of the dummy VM in memory of the destination host computer, the source host computer being in the first cluster, and the destination host computer being in the second cluster (Col. 1 Lines 24-32 states “For example, the partitions can share the memory, the kernel, the processors, the hard drives, and/or other software, firmware, and/or hardware of the host. Thus, each partition or instance of the operating system can look and feel like a separate server or machine from the perspective of its users. These instances are commonly referred to as “virtual” or “virtualized” machines, and each partition may be referred to as a logical partition (LPAR).” Col. 11 Lines 32-35 states “at step 450, the process performs a trial migration of the new instance (test LPAR 321) created in source system 310 to target system 312.” Col. 7 Lines 30-34 states “LPAR 322 is created matching the instance of LPAR 321 that was created on source system 310. A trial migration is performed of snapshot OS 325 running in LPAR 321 on system 310 to target LPAR 322 on system 312.” Examiner’s Note: LPARs share memory and hard disks of the host system, so LPARs have a virtual disk. When LPAR’s are migrated, they are replicating source LPAR state. Therefore, LPAR’s memory and virtual disks are transferred to the destination host computer ), and wherein migrating the target VM from the source host computer to the destination host computer includes transmitting, from the first cluster to the second cluster, a second virtual disk of the target VM and memory contents of the target VM, and then storing the transmitted second virtual disk in the storage of the second cluster and storing the transmitted memory contents of the target VM in the memory of the destination host computer (Col. 7 Lines 34-36 states “If the trial migration is successful, then the live instance of the virtual machine is migrated from LPAR 320 on source system 310 to LPAR 322 on target system 312.” Examiner’s Note: as explained above in the previous Examiner’s Note, the transfer of LPAR includes the transfer of a virtual disk and memory ). Hart, Zlotnick, and Price do not explicitly teach source and destination clusters of hosts. However, in an analogous art, Ekbote teaches wherein migrating the dummy VM from the source host computer to the destination host computer includes transmitting, from a first cluster of host computers to a second cluster of host computers, a first virtual disk of the dummy VM and memory contents of the dummy VM, and then storing the transmitted first virtual disk in storage of the second cluster and storing the transmitted memory contents of the dummy VM in memory of the destination host computer, the source host computer being in the first cluster, and the destination host computer being in the second cluster (¶ [0002] states “A group of hardware computing platforms may be organized as a cluster to provide resources for VMs. In a data center, it is common to see hundreds, even thousands, of VMs running on multiple clusters of hosts.” ¶ [0021] states “As shown, cross-site computing system 100 includes a source data center 102S and a destination computing system 102D. In one embodiment, source and destination computing systems 102S and 102D may be virtualized computing systems” and “discussed herein primarily with respect to a VM transfer from data center 102S to data center 102D.” See FIG. 1A. Examiner’s Note: source data center 102S represents a first cluster that includes the source host computer and destination data center 102D represents a second cluster that includes the destination host computer ), and wherein migrating the target VM from the source host computer to the destination host computer includes transmitting, from the first cluster to the second cluster, a second virtual disk of the target VM and memory contents of the target VM, and then storing the transmitted second virtual disk in the storage of the second cluster and storing the transmitted memory contents of the target VM in the memory of the destination host computer (¶ [0021] states “As shown, cross-site computing system 100 includes a source data center 102S and a destination computing system 102D. In one embodiment, source and destination computing systems 102S and 102D may be virtualized computing systems” and “discussed herein primarily with respect to a VM transfer from data center 102S to data center 102D.” See FIG. 1A. Examiner’s Note: source data center 102S has at least a first cluster that includes the source host computer and destination data center 102D has at least a second cluster that includes the destination host computer ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine source and destination clusters of Ekbote with the virtual machine migration using a test copy of Hart, the matching network configurations of dummy and migrated VMs of Zlotnick, and the testing of network connections between virtual machines of Price. As a result, the hosts in the virtual machine migration of Hart are located in data centers that represent clusters. A person having ordinary skill in the art would have been motivated to make this combination “to provide resources for VMs” (¶ [0002]). Additionally, by having the environment of data centers and clusters, “A particular path can then be selected for a VM transfer based on the stored information before initiating the transfer, thereby improving usage of resources and increasing the likelihood of the VM transfer's success” (¶ [0107]) . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20150234907 A1 teaches TEST ENVIRONMENT MANAGEMENT APPARATUS AND TEST ENVIRONMENT CONSTRUCTION METHOD US 20230136363 A1 teaches Methods And Systems For Storage Virtual Machine Migration Between Clusters Of A Networked Storage System US 20150200808 A1 teaches Features of claims 7 and 13 such as number of vNICs and maximum transmission unit Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER L YUAN whose telephone number is (571)272-5737. The examiner can normally be reached Mon-Fri 7:30am-5pm. 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, Bradley Teets can be reached at 571-272-3338. 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. /PETER LI YUAN/Examiner, Art Unit 2197 /MELISSA A HEADLY/Examiner, Art Unit 2197 Application/Control Number: 18/657,706 Page 2 Art Unit: 2197 Application/Control Number: 18/657,706 Page 3 Art Unit: 2197 Application/Control Number: 18/657,706 Page 4 Art Unit: 2197 Application/Control Number: 18/657,706 Page 5 Art Unit: 2197 Application/Control Number: 18/657,706 Page 6 Art Unit: 2197 Application/Control Number: 18/657,706 Page 7 Art Unit: 2197 Application/Control Number: 18/657,706 Page 8 Art Unit: 2197 Application/Control Number: 18/657,706 Page 9 Art Unit: 2197 Application/Control Number: 18/657,706 Page 10 Art Unit: 2197 Application/Control Number: 18/657,706 Page 11 Art Unit: 2197 Application/Control Number: 18/657,706 Page 12 Art Unit: 2197 Application/Control Number: 18/657,706 Page 13 Art Unit: 2197 Application/Control Number: 18/657,706 Page 15 Art Unit: 2197 Application/Control Number: 18/657,706 Page 16 Art Unit: 2197 Application/Control Number: 18/657,706 Page 17 Art Unit: 2197 Application/Control Number: 18/657,706 Page 18 Art Unit: 2197 Application/Control Number: 18/657,706 Page 19 Art Unit: 2197 Application/Control Number: 18/657,706 Page 20 Art Unit: 2197 Application/Control Number: 18/657,706 Page 21 Art Unit: 2197 Application/Control Number: 18/657,706 Page 23 Art Unit: 2197 Application/Control Number: 18/657,706 Page 24 Art Unit: 2197 Application/Control Number: 18/657,706 Page 25 Art Unit: 2197 Application/Control Number: 18/657,706 Page 26 Art Unit: 2197 Application/Control Number: 18/657,706 Page 27 Art Unit: 2197 Application/Control Number: 18/657,706 Page 28 Art Unit: 2197 Application/Control Number: 18/657,706 Page 29 Art Unit: 2197 Application/Control Number: 18/657,706 Page 30 Art Unit: 2197 Application/Control Number: 18/657,706 Page 31 Art Unit: 2197 Application/Control Number: 18/657,706 Page 32 Art Unit: 2197 Application/Control Number: 18/657,706 Page 33 Art Unit: 2197 Application/Control Number: 18/657,706 Page 34 Art Unit: 2197 Application/Control Number: 18/657,706 Page 35 Art Unit: 2197 Application/Control Number: 18/657,706 Page 36 Art Unit: 2197 Application/Control Number: 18/657,706 Page 37 Art Unit: 2197 Application/Control Number: 18/657,706 Page 38 Art Unit: 2197 Application/Control Number: 18/657,706 Page 39 Art Unit: 2197 Application/Control Number: 18/657,706 Page 40 Art Unit: 2197 Application/Control Number: 18/657,706 Page 41 Art Unit: 2197 Application/Control Number: 18/657,706 Page 42 Art Unit: 2197 Application/Control Number: 18/657,706 Page 43 Art Unit: 2197 Application/Control Number: 18/657,706 Page 44 Art Unit: 2197 Application/Control Number: 18/657,706 Page 45 Art Unit: 2197 Application/Control Number: 18/657,706 Page 46 Art Unit: 2197 Application/Control Number: 18/657,706 Page 47 Art Unit: 2197 Application/Control Number: 18/657,706 Page 48 Art Unit: 2197 Application/Control Number: 18/657,706 Page 49 Art Unit: 2197 Application/Control Number: 18/657,706 Page 50 Art Unit: 2197 Application/Control Number: 18/657,706 Page 51 Art Unit: 2197 Application/Control Number: 18/657,706 Page 52 Art Unit: 2197 Application/Control Number: 18/657,706 Page 53 Art Unit: 2197 Application/Control Number: 18/657,706 Page 54 Art Unit: 2197
Prosecution Insights