Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1-3, 5-10, 12-17 and 19-20 are currently pending and have been examined.
Claim Objections
Claim 6, 13 and 20 are objected to because of the following informalities:
Re-claim 6, the claim recites as being dependent on cancelled claim 4, when it should depend on claim 1.
Re-claim 13, the claim recites as being dependent on cancelled claim 11, when it should depend on claim 8.
Re-claim 20, the claim recites as being dependent on cancelled claim 18, when it should depend on claim 15.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5-6, 8-9, 12-13, 15-16 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ganesan et al. (U.S. Pub. No. 20170039082 A1) in view of Xiao et al. (U.S. Pub. No. 20230115261 A1), and further in view of Shan et al. (U.S. Pub. 20230283479 A1).
Ganesan was cited in a previous office action.
As per claim 1, Ganesan teaches the invention substantially as claimed including a virtual-machine cold migration (par. 0035 Migrating a suspended virtual machine) method, comprising:
selecting a node as a target physical machine from nodes of a cluster where a to-be-migrated virtual machine is located, the target physical machine and a source physical machine where the virtual machine is located being different nodes (par. 0041 At 230 in FIG. 2, management entity 150 selects a target host (also referred to as “second host”) from cluster 105. For example, Host-C 110C is selected as a target host for VM1 131 and Host-B 110B for VM2 132. The target hosts may be selected based on any suitable criteria, such as status of their connection to storage network 146, host utilization value representing the current load of each target host; Further, it is noted, for example, Fig. 1, describes migrating VM1 in Host A 110A to Host C 110C); and
migrating … system disk data and data disk data in the virtual machine from the source physical machine to the target physical machine to obtain a migrated virtual machine (par. 0042 At 240 in FIG. 2, management entity 150 instructs Host-A 110A via management network 140 to migrate suspended VM1 131 … to selected Host-C 110C; par. 0035 Migrating a suspended virtual machine may involve moving any suitable information of the virtual machine from a source host to a target host, such as the stored state information, non-volatile random access memory (NVRAM) files (e.g., includes basic input/output system (BIOS) settings), suspend files as well as virtual disks [system disk data] of the virtual machine), and deleting the virtual machine on the source physical machine (par. 0034 … After the migration is complete, an old version of the virtual machine is deleted from the source host),
Ganesan does not expressly disclose: migrating, by means of point-to-point data transmission; wherein the migrating system disk data in the virtual machine from the source physical machine to the target physical machine comprises: creating an ephemeral source system pod running on the source physical machine, and mounting a source system disk in the ephemeral source system pod; creating an ephemeral target system pod running on the target physical machine, and mounting a target system disk in the ephemeral target system pod; and using the ephemeral source system pod and the ephemeral target system pod as a data sender and a data receiver respectively, and transmitting the system disk data from the source system disk to the target system disk using a data transmission manner of a hypertext transfer protocol transmission manner therebetween.
However, analogous prior art Xiao teaches:
migrating, by means of point-to-point data transmission (par. 0016 source-side and destination-side PV transfer processes can work in concert to securely copy (using, e.g., a data synchronization tool such as Rsync and a secure network protocol such as Secure Shell (SSH)). Examiner notes, SSH protocol that functions as point to point data transmission protocol creating encrypted channel between two computers/devices).
wherein the migrating system disk data in the virtual machine [workload] from the source physical machine to the target physical machine comprises: creating an ephemeral source system pod running on the source physical machine, and mounting a source system disk in the ephemeral source system pod (par. 0015 techniques involve creating and running, at the time of the migration, persistent volume (PV) transfer processes (or PV transfer “pods” in Kubernetes parlance) in the source and destination container clusters … where (1) the source-side PV transfer process mounts the workload's persistent volumes (referred to as source persistent volumes) in the source container cluster; par. 0026 because migration pod 204 launches PV transfer pods 216(1) and 216(2) on-demand at the time of workload migration (and can delete/remove these PV transfer pods once the migration is complete). It is noted, that because the PV transfer pods are created on demand and can then be deleted/removed once migration is completed, they are temporary and as such are equivalent to ephemeral system pods);
creating an ephemeral target system pod running on the target physical machine, and mounting a target system disk in the ephemeral target system pod (par. 0015 techniques involve creating and running, at the time of the migration, persistent volume (PV) transfer processes (or PV transfer “pods” in Kubernetes parlance) in the source and destination container clusters … and (2) the destination-side PV transfer process mounts destination persistent volumes that have been dynamically provisioned in the destination container cluster; par. 0026 because migration pod 204 launches PV transfer pods 216(1) and 216(2) on-demand at the time of workload migration (and can delete/remove these PV transfer pods once the migration is complete). It is noted, that because the PV transfer pods are created on demand and can then be deleted/removed once migration is completed, they are temporary and as such are equivalent to ephemeral system pods); and
using the ephemeral source system pod and the ephemeral target system pod as a data sender and a data receiver respectively, and transmitting the system disk data from the source system disk to the target system disk using a data transmission manner of a … transfer protocol transmission manner therebetween (par. 0016 Upon being created and run, the source-side and destination-side PV transfer processes can work in concert to securely copy (using, e.g., a data synchronization tool such as Rsync and a secure network protocol such as Secure Shell (SSH)) the data in the source persistent volumes to their corresponding destination persistent volumes, thereby transferring that data between the storage backends of the source and destination container clusters without having to use an intermediary repository. Examiner notes, SSH protocol is equivalent to a hypertext transfer protocol, because they both function as point-to-point data transmission protocol to establish/create encrypted connection/channel between two computers/devices).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine/modify the technique for migrating a stateful workload from a source container cluster to a destination container cluster of Xiao with the method and system of Ganesan resulting in a system/method for migrating virtual machine virtual disk data [system disk data] in a manner creating and running, at the time of the migration, transfer “pods” in the source and destination hosts using the source pod/containers to transfer the virtual machine virtual disk data to the destination pod of the destination host, and using a least a SSH transfer protocol. A person of ordinary skill in the art would have been motivated to make this combination because it would provide the ability to launch transfer pods on the source and destination hosts on-demand at the time of workload/VM migration, and the ability to delete/remove these transfer pods once the migration is complete results in not needing to maintain long-lived, privileged backup-and-restore pods in the source or destination container clusters/hosts that are vulnerable to attacks. This, along with the use of a secure network protocol between transfer source and destination pods, results in significantly increased security (par. 0026).
Ganesan and Xiao do not expressly disclose: transmitting … using a data transmission manner of a hypertext transfer protocol transmission manner therebetween.
However, Shan teaches: transmitting … using a data transmission manner of a hypertext transfer protocol transmission manner therebetween (par. 0078 In an example, the source end 100 may establish a communication connection to the destination end 200 by using the hypertext transfer protocol (HTTP) or the hypertext transfer protocol secure (HTTPS), and transmit the to-be-transmitted data to the destination end).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique using the hypertext transfer protocol (HTTP) to transmit a to-be-transmitted data from a source server to a destination server of Xiao with the methods and systems of Ganesan and Xiao resulting in a system/method for migrating virtual machine virtual disk data [system disk data] in a manner of creating and running, at the time of the migration, transfer “pods” in the source and destination hosts using the source pod/containers and the hypertext transfer protocol of Shan to transfer the virtual machine virtual disk data to the destination pod of the destination host. A person of ordinary skill in the art would have been motivated to make this combination for the purpose of improving transmission efficiency of the to-be-transmitted resource between the source end and the destination (par. 0030) and further improving data verification reliability (0032).
As per claim 2, Ganesan further teaches: filtering out the source physical machine and nodes which cannot meet a resource configuration requirement of the virtual machine from the nodes in the cluster, using remaining nodes as candidate nodes, and selecting one node from the candidate nodes as the target physical machine (par. 0041 The target hosts may be selected based on any suitable criteria, such as status of their connection to storage network 146, host utilization value representing the current load of each target host, VM network connectivity. Thus, it implicit that the source host and other hosts that do not meet the criteria are filtered out).
As per claim 5, Ganesan further teaches: wherein the migrating data disk data in the virtual machine from the source physical machine to the target physical machine comprises: processing any data disk in the virtual machine (par. 0042 At 240 in FIG. 2, management entity 150 instructs Host-A 110A via management network 140 to migrate suspended VM1 131 … to selected Host-C 110C; par. 0035 Migrating a suspended virtual machine may involve moving any suitable information of the virtual machine from a source host to a target host, such as the stored state information [data disk data], non-volatile random access memory (NVRAM) files (e.g., includes basic input/output system (BIOS) settings), suspend files as well as virtual disks of the virtual machine)) by:
Ganesan, Shan do not expressly teach: processing any data disk in the virtual machine by: creating an ephemeral source data pod running on the source physical machine, and mounting a source data disk in the ephemeral source data pod.
However, Xiao further teaches: processing any data disk in the virtual machine by: creating an ephemeral source data pod running on the source physical machine, and mounting a source data disk in the ephemeral source data pod (par. 0015 techniques involve creating and running, at the time of the migration, persistent volume (PV) transfer processes (or PV transfer “pods” in Kubernetes parlance) in the source and destination container clusters … where (1) the source-side PV transfer process mounts the workload's persistent volumes (referred to as source persistent volumes) in the source container cluster; par. 0026 because migration pod 204 launches PV transfer pods 216(1) and 216(2) on-demand at the time of workload migration (and can delete/remove these PV transfer pods once the migration is complete). It is noted, that because the PV transfer pods are created on demand and can then be deleted/removed once migration is completed, they are temporary and as such equivalent to ephemeral system pods); creating an ephemeral target data pod running on the target physical machine, and mounting a target data disk in the ephemeral target data pod (par. 0015 techniques involve creating and running, at the time of the migration, persistent volume (PV) transfer processes (or PV transfer “pods” in Kubernetes parlance) in the source and destination container clusters … and (2) the destination-side PV transfer process mounts destination persistent volumes that have been dynamically provisioned in the destination container cluster; par. 0026 because migration pod 204 launches PV transfer pods 216(1) and 216(2) on-demand at the time of workload migration (and can delete/remove these PV transfer pods once the migration is complete). It is noted, that because the PV transfer pods are created on demand and can then be deleted/removed once migration is completed, they are temporary and as such equivalent to ephemeral system pods); and using the ephemeral source data pod and the ephemeral target data pod as a data sender and a data receiver respectively, and transmitting the data disk data from the source data disk to the target data disk (par. 0016 Upon being created and run, the source-side and destination-side PV transfer processes can work in concert to securely copy (using, e.g., a data synchronization tool such as Rsync and a secure network protocol such as Secure Shell (SSH)) the data in the source persistent volumes to their corresponding destination persistent volumes, thereby transferring that data between the storage backends of the source and destination container clusters without having to use an intermediary repository; par. 0026 because migration pod 204 launches PV transfer pods 216(1) and 216(2) on-demand at the time of workload migration (and can delete/remove these PV transfer pods once the migration is complete). It is noted, that because the PV transfer pods are created on demand and can then be deleted/removed once migration is completed, they are temporary and as such are equivalent to ephemeral system pods).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the technique for migrating a stateful workload from a source container cluster to a destination container cluster of Xiao with the methods/systems of Ganesan and Shan resulting in a system/method for migrating virtual machine state information data [data disk data] in a manner creating and running, at the time of the migration, transfer “pods” in the source and destination hosts using the source pod/containers to transfer the state information data [data disk data] to the destination pod of the destination host, and using a least a SSH transfer protocol. A person of ordinary skill in the art would have been motivated to make this combination because it would provide the ability to launch transfer pods on the source and destination hosts on-demand at the time of workload/VM migration, and the ability to delete/remove these transfer pods once the migration is complete results in not needing to maintain long-lived, privileged backup-and-restore pods in the source or destination container clusters/hosts that are vulnerable to attacks. This, along with the use of a secure network protocol between transfer source and destination pods, results in significantly increased security (par. 0026).
As per claim 6, Xiao further teaches: wherein the data sender and the data receiver further use at least one of the following mechanisms: an authentication and verification mechanism before data transmission and an error retry mechanism in the data transmission process (par. 0016 Upon being created and run, the source-side and destination-side PV transfer processes can work in concert to securely copy (using, e.g., a data synchronization tool such as Rsync and a secure network protocol such as Secure Shell (SSH)) the data in the source persistent volumes to their corresponding destination persistent volumes. Examiner notes that Secure Shell (SSH) is build/has robust authentication and verification processes).
As per claim 8, it is an electronic device having similar limitations as claim 1. Thus, claim 8 is rejected for the same rationale as applied to claim 1. Ganesan further teaches: at least one processor (Fig. 8, Processor 810); and a memory connected with the at least one processor communicatively (Fig. 8, Computer-readable storage medium 820); wherein the memory stores instructions executable by the at least one processor (par. 0097 Computer-readable storage medium 820 may further store computer-readable instructions 824 which, in response to execution by processor 810, cause processor 810 to perform processes).
As per claim 9, it is an electronic device having similar limitations as claim 2. Thus, claim 9 is rejected for the same rationale as applied to claim 2.
As per claim 12, it is an electronic device having similar limitations as claim 5. Thus, claim 12 is rejected for the same rationale as applied to claim 5.
As per claim 13, it is an electronic device having similar limitations as claim 6. Thus, claim 13 is rejected for the same rationale as applied to claim 6.
As per claim 15, it is a non-transitory computer readable storage medium having similar limitations as claim 1. Thus, claim 15 is rejected for the same rationale as applied to claim 1. Further, Ganesan further teaches: non-transitory computer readable storage medium (par. 0100 Computer-readable storage medium 820).
As per claim 16, it is a non-transitory computer readable storage medium having similar limitations as claim 2. Thus, claim 16 is rejected for the same rationale as applied to claim 2.
As per claim 19, it is a non-transitory computer readable storage medium having similar limitations as claim 5. Thus, claim 19 is rejected for the same rationale as applied to claim 5.
As per claim 20, it is a non-transitory computer readable storage medium having similar limitations as claim 6. Thus, claim 20 is rejected for the same rationale as applied to claim 6.
Claims 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ganesan in view of Xiao and Shan, and further in view of Dai et al. (U.S. Pub. No. 20180300206 A1).
As per claim 3, Ganesan further teaches: wherein the selecting one node from the candidate nodes as the target physical machine comprises: selecting one node … [based on based on any suitable criteria] from the candidate nodes as the target physical machine (par. 0041 the target hosts may be selected based on any suitable criteria, such as … host utilization value).
Ganesan, Xiao and Shan do not expressly teach: selecting one node with an optimal comprehensive performance from the candidate nodes as the target physical machine.
However, Dai teaches: selecting one node with an optimal comprehensive performance from the candidate nodes as the target physical machine (par. 0039 the manager node 202 may select a node with the optimal performance data as the backup node).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine/modify the technique for select a node with the optimal performance data as the backup node of Dai with the methods and systems of Ganesan, Xiao and Shan resulting in a system/method for migrating virtual machine by selecting a node/host with the optimal performance data as the destination host, migrating state data/virtual disk data in a manner creating and running, at the time of the migration, transfer “pods” in the source and destination hosts using the source pod to transfer the virtual machine state data and virtual disk data to the destination pod of the destination host, and using a least a SSH transfer protocol. A person of ordinary skill in the art would have been motivated to make this combination for the purpose of can improving fault tolerance of the cluster system so that data backup/migration can be completed successfully (par. 0005).
As per claim 10, it is an electronic device having similar limitations as claim 3. Thus, claim 10 is rejected for the same rationale as applied to claim 3.
As per claim 17, it is a non-transitory computer readable storage medium having similar limitations as claim 3. Thus, claim 17 is rejected for the same rationale as applied to claim 3.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ganesan in view of Xiao and Shan as applied to claims 1, 8 and 15, and further in view of ZHU et al. (U.S. Pub. No. 20180060101 A1).
As per claim 7, Ganesan, Xiao and Shan do not expressly describe: acquiring and displaying migration progress information of the cold migration process in real time.
However, ZHU teaches: acquiring and displaying migration progress information of the cold migration process in real time (par. 0091 a migration dashboard for providing status information on the migration of the virtual machine is displayed; par. 0076; Migration dashboard 760 illustrates the status of all virtual machine migrations that have been initiated. For example, migration dashboard 760 may show, for each virtual machine, the source of a migration, the destination of the migration, a status update, a percentage complete, a size of the migration, and a remaining time until the migration is complete).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of using migration dashboard to show/display migration information of ZHU with the system/method of Ganesan, Xiao and Shan resulting in a system/method for migrating virtual machine virtual disk data [system data] using transfer “pods” and monitoring migration progress using the migration dashboard of ZHU. A person of ordinary skill in the art would have been motivated to make this combination because it would allow users to perform operations such as cancelling a migration (or scheduled migration), troubleshooting a migration, or restarting a migration (par. 0076) in view of the information displayed in the dashboard.
As per claim 14, it is an electronic device having similar limitations as claim 7. Thus, claim 14 is rejected for the same rationale as applied to claim 7.
Response to Arguments
Applicant's arguments with respect to claims 1, 8 and 15 have been considered but are moot in view of the new ground(s) of rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Willy W. Huaracha whose telephone number is (571)270-5510. The examiner can normally be reached on M-F 8:30-5:00pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached on (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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WH/
Examiner, Art Unit 2195
/BRADLEY A TEETS/ Supervisory Patent Examiner, Art Unit 2197