DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to Amendment filed on 11/26/2025, claiming priority based on provisional application 62/265339 dated 12/9/2015, wherein claims 1-20 are pending and claims 1 and 11 are amended.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over the reference patent (PAT 10949240) Although the claims at issue are not identical, they are not patentably distinct from each other.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
A claim has been mapped out below as example wherein functionally:
Reference Patent
Instant Application
1. A system for synchronizing a virtual machine to another virtual machine, the system comprising:
a first virtual machine server comprising one or more processors and computer memory, wherein a first virtual machine executes over a first hypervisor operating on the first virtual machine server;
a first data agent associated with the first virtual machine server, wherein the first data agent executes on a computing device comprising one or more processors and computer memory;
a second data agent associated with a second virtual machine server that is distinct from the first virtual machine server, wherein the second data agent executes on a computing device comprising one or more processors and computer memory;
wherein the first data agent is configured to generate, at least in part, a first full backup copy of the first virtual machine,
wherein the first full backup copy is stored to a first secondary storage device, and
wherein the first full backup copy comprises, in a hypervisor-independent format, one or more configuration parameters of the first virtual machine converted into the hypervisor-independent format by the first data agent associated with the first virtual machine server;
wherein the second data agent is configured to cause a second virtual machine, based on the one or more configuration parameters of the first virtual machine, to be configured over a second hypervisor operating on the second virtual machine server;
wherein the second data agent is further configured to: (a) obtain the one or more configuration parameters from the first full backup copy of the first virtual machine, (b) convert the one or more configuration parameters from the hypervisor-independent format into a format suitable for the second hypervisor, and (c) instruct the second virtual machine server to configure the second virtual machine according to the one or more configuration parameters converted into the format suitable for the second hypervisor;
wherein the second data agent is further configured to, at least in part, restore the first full backup copy to the second virtual machine in a native format accessible to the second virtual machine;
wherein the first data agent is further configured to generate, at least in part, successive incremental backup copies of the first virtual machine, each successive incremental copy comprising changes relative to a preceding backup copy of the first virtual machine; and
wherein the second data agent is further configured to, at least in part, restore each successive incremental backup copy to the second virtual machine, thereby synchronizing the second virtual machine to the first virtual machine.
1. A computer-implemented method comprising:
performing a backup operation that generates a first backup copy of first primary data of a first virtual machine,
wherein the first virtual machine is hosted by a first hypervisor operating on a first virtual machine server, which comprises one or more hardware processors and computer memory, and
wherein the first backup copy comprises one or more configuration parameters of the first virtual machine; by a first computing resource, obtaining, from the first backup copy, the one or more configuration parameters of the first virtual machine;
by the first computing resource, causing a second virtual machine to be configured in a cloud computing environment, wherein configuring the second virtual machine comprises converting the one or more configuration parameters into a format suitable for the cloud computing environment;
performing successive incremental backup operations to generate incremental backup copies of the first primary data;
restoring the first backup copy and one or more of the incremental backup copies into second primary data, wherein the second primary data is stored in a second data storage resource that is configured in the cloud computing environment, and activating the second virtual machine, wherein the restoring is performed periodically to maintain the second virtual machine in a synchronized, non-executing warm standby state that is updated based on the incremental backup copies; and
automatically in response to detecting failure of the first virtual machine, activating the second virtual machine uses the second primary data from the second data storage resource as a source of primary data for the second virtual machine.
The examiner recognizes that while the claim limitations are not exactly the same between the reference patent and the present application, the reference patent’s claim limitations includes each and every element of the present application, and thus anticipates each and every element of the present application. Thus, they are not patentably distinct from each other.
As for claims 2-10 and 11-20, they contain similar limitations as claims 1-12 of the reference patent and are similarly patentably indistinct from each other.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over the reference patent (PAT 11803411) Although the claims at issue are not identical, they are not patentably distinct from each other.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
A claim has been mapped out below as example wherein functionally:
Reference Patent
Instant Application
1. A computer-implemented method comprising:
generating a first full backup copy of first primary data of a first virtual machine,
wherein the first virtual machine is hosted by a first hypervisor operating on a first virtual machine server comprising one or more processors and computer memory,
wherein the first full backup copy comprises one or more configuration parameters of the first virtual machine, and
wherein the first full backup copy comprises the one or more configuration parameters in a hypervisor-independent format;
by a second data agent associated with a second virtual machine server, obtaining the one or more configuration parameters of the first virtual machine, from the first full backup copy, wherein the second virtual machine server comprises one or more processors and computer memory and operates in a cloud computing environment and executes a second hypervisor;
by the second data agent, configuring a second virtual machine at the second hypervisor, wherein the configuring comprises converting the one or more configuration parameters from the hypervisor-independent format into a format suitable for the second hypervisor;
restoring the first full backup copy to a second data storage resource, which is configured in the cloud computing environment and is associated with the second virtual machine;
generating successive incremental backup copies of the first primary data,
wherein each successive incremental backup copy comprises changes compared to a preceding backup copy of the first primary data;
restoring the successive incremental backup copies to the second data storage resource associated with the second virtual machine; and
activating the second virtual machine, wherein the activated second virtual machine uses restored data, which is based on the first primary data of the first virtual machine, in the second data storage resource as a source of primary data for the second virtual machine.
1. A computer-implemented method comprising:
performing a backup operation that generates a first backup copy of first primary data of a first virtual machine,
wherein the first virtual machine is hosted by a first hypervisor operating on a first virtual machine server, which comprises one or more hardware processors and computer memory, and
wherein the first backup copy comprises one or more configuration parameters of the first virtual machine;
by a first computing resource, obtaining, from the first backup copy, the one or more configuration parameters of the first virtual machine;
by the first computing resource, causing a second virtual machine to be configured in a cloud computing environment, wherein configuring the second virtual machine comprises converting the one or more configuration parameters into a format suitable for the cloud computing environment;
performing successive incremental backup operations to generate incremental backup copies of the first primary data;
restoring the first backup copy and one or more of the incremental backup copies into second primary data, wherein the second primary data is stored in a second data storage resource that is configured in the cloud computing environment, and activating the second virtual machine, wherein the restoring is performed periodically to maintain the second virtual machine in a synchronized, non-executing warm standby state that is updated based on the incremental backup copies; and
automatically in response to detecting failure of the first virtual machine, activating the second virtual machine uses the second primary data from the second data storage resource as a source of primary data for the second virtual machine.
The examiner recognizes that while the claim limitations are not exactly the same between the reference patent and the present application, the reference patent’s claim limitations includes each and every element of the present application, and thus anticipates each and every element of the present application. Thus, they are not patentably distinct from each other.
As for claims 2-10 and 11-20, they contain similar limitations as claims 1-8 of the reference patent and are similarly patentably indistinct from each other.
Information Disclosure Statement
The information disclosure statement filed 5/14/2024 fails to comply with 37 CFR 1.98(a)(2), which requires a legible copy of each cited foreign patent document; each non-patent literature publication or that portion which caused it to be listed; and all other information or that portion which caused it to be listed. Examiner crossed out the specific listed NPL that is missing the legible copy required. It has been placed in the application file, but the information referred to therein has not been considered.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-4, 6 9-12, 15, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Behere et al. (US PGPUB 2016/0335106), and further in view of Deshpande et al. (US PGPUB 2014/0181813), further in view of Chan et al. (US PGPUB 20140149354).
As for claim 1, Behere teaches a computer-implemented method comprising:
performing a backup operation that generates a first backup copy of first primary data of a first virtual machine (In a first embodiment, paragraph 37, “…store a source VM virtual disk…arrangement of blocks corresponding to a virtual disk format used by the source hypervisor…”, paragraph 38, “…each of the source VM virtual disk….may have one or more blocks dedicated to storage of data and metadata…” paragraph 40, “…prior to migration, the data for the VMs…” teaches the creation of the source VM virtual disk stored inside a data storage 112/ONTAP storage cluster. In an alternative embodiment, paragraph 58, “…generated destination disks…” teaches based on source VM virtual disk, generating a destination disks capable of being used to create a destination VM, thus, the destination disks generated, but before actual use by destination VM, is also a form of backup disk that corresponds to the source VM),
wherein the first virtual machine is hosted by a first hypervisor operating on a first virtual machine server, which comprises one or more hardware processors and computer memory (paragraph 32, “…source VM managed by a source hypervisor…” in view of paragraph 22, “…execution environment platform 108 …abstracts a hardware platform…providing of the virtual machine performed by a hypervisor 110…runs on an actual hardware platform…” and paragraph 63, “…common computing elements, such as one or more processors…memory units…”),
wherein the first backup copy comprises one or more configuration parameters of the first virtual machine (paragraph 38, “each of the …virtual disk…may have one or more blocks dedicated to storage of data and metadata used by the …hypervisor….for managing its access to the common blocks…” the data and metadata are understood as forms of configuration parameters related to the management of blocks within the virtual disks (source VM virtual disk and/or copied to and created destination VM virtual disk in view of above mappings) are clearly for managing the common blocks, which is understood as a form of configuration parameter. In an alternative embodiment, paragraph 46-49, “for migrating a vm….a configuration maybe established …using configuration cmdlets…specify details of the source hypervisors..VMs..guest OS, and/or storage components…as well as details regarding the network configuration of the source VM…may include an NIC-to-MAC mapping…include locations of any storage resources used by the source VM…” configuration information generated and associated with the source VM virtual disk to be migrated can be understood as claimed configuration parameters as well.);
by a first computing resource, obtaining, from the first backup copy, the one or more configuration parameters of the first virtual machine (First embodiment, paragraph 53-54, “…configuration maybe established…convert command may specify a name of a VM, as well as a direction of conversion…utilize …the configuration information…” teaches obtaining the configuration information and converting it, to convert it would obviously require obtaining the configuration information to convert from. Second embodiment, paragraph 57, “discovers …data from the source VM….calls the disk conversion library to convert the source VM data into a format compatible with …”in view of paragraph 38, “virtual disk may have one or more blocks dedicated to storage of data and metadata used by the source hypervisor….not accessible to the guest OS…for managing its access to the common blocks…” teaches a different set of configuration information of the source VM that is accessed and configured. teaches converting (which clearly includes obtaining) the source VM data);
by the first computing resource, causing a second virtual machine to be configured in a computing environment, wherein configuring the second virtual machine comprises converting the one or more configuration parameters into a format suitable for the cloud computing environment (First embodiment, paragraph 53-54, “…configuration maybe established…convert command may specify a name of a VM, as well as a direction of conversion…utilize …the configuration information…” teaches obtaining the configuration information and converting it. Second embodiment, paragraph 57, “discovers …data from the source VM….calls the disk conversion library to convert the source VM data into a format compatible with …”in view of paragraph 38, “virtual disk may have one or more blocks dedicated to storage of data and metadata used by the source hypervisor….not accessible to the guest OS…for managing its access to the common blocks…” teaches a different set of configuration information of the source VM that is accessed and configured. teaches the source VM data that includes configuration data. Paragraph 57-58, “converted data from the source VM …stored…calls the disk conversion library to convert the source VM data into a format compatible with the destination VM disk type…generated destination disks …creates a new VM using the generated destination disks at step 420…” and paragraphs 52-54, “…VM configuration…list of virtual disks with backend storage locations…NIC cards associated with the VM; and a disk driver mapping, among other…convert command may utilize…the configuration information …” in view of paragraph 58 teaches use of converted parameters and disks containing the parameters are used as part of configure/create the second/destination VM);
activating the second virtual machine, wherein the activated second virtual machine uses the first primary data from the first data storage resource [destination path] as a source of primary data for the second virtual machine (paragraph 57, migration server …calls the Disk Conversion Library to convert the source VM data into a format compatible with the destination VM disk type…paragraph 58, “…creates a VM using the generated destination disk at step 420”).
While Behere teaches virtual machine migration including using a copy of the primary data of the first virtual machine. Behere does not explicitly teach restoring the first backup copy and one or more of the incremental backup copies into second primary data, wherein the second primary data is stored in a second data storage resource that is configured in the cloud computing environment and activating the second virtual machine using the second primary data from the second data storage resource as a source of primary data for the second virtual machine.
Deshpande teaches a known method of virtual machine migration/backup/archiving/restoration in a networked environment including virtual machine executing in a cloud computing environment (paragraph 61) performing successive incremental backup operations to generate incremental backup copies of the first primary data (paragraph 170-172, “…incremental backup operation…tracks and stores changes that have occurred since the last full backup…”)
restoring the first backup copy and one or more of the incremental backup copies into second primary data, wherein the second primary data is stored in a second data storage resource that is configured in the cloud computing environment (paragraph 168-172, “…backup operation creates a copy of primary data….subsequent backup copy maybe maintained independently of the first incremental backup operation…restore operation …involve accessing a full backup in addition to …incremental backup…”); and
Activating a virtual machine uses the second primary data from the second data storage resource as a source of primary data for the virtual machine (paragraph 291, 295, 297, 305, 307). This known technique is applicable to the system of Behere as they both share characteristics and capabilities, namely, they are directed to virtual machine management in a networked environment including VM migration.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Deshpande would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Deshpande to the teachings of Behere would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine management into similar systems. Further, applying performing successive incremental backup operations to generate incremental backup copies of the first primary data, restoring the first backup copy and one or more of the incremental backup copies into second primary data, wherein the second primary data is stored in a second data storage resource that is configured in the cloud computing environment , and activating a virtual machine in a cloud computing environment uses the second primary data from the second data storage resource as a source of primary data for the virtual machine to Behere with backing up copy of a first virtual machine, and restoring the backed up copy into a second virtual machine accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow reduced storage requirements for dynamic and continuous virtual machine backups. (Deshpande, paragraph 172).
While Deshpande teaches a method of restoring VM using incremental backups, Behere and Deshpande do not explicitly teach the system periodically restore the incremental backup copies into a second primary data before detecting a failure of the first virtual machine.
However, Chan teaches a known method of VM backup and restoration using incremental/delta images (paragraph 38 and 40) including the restoring is performed periodically to maintain the second virtual machine in a synchronized, non-executing warm standby state that is updated based on the incremental backup copies (paragraph 40, determining a delta image…transmitting the delta image…merging the received delta images with a recovery image …to update the recovery image…”) and automatically in response to detecting failure of the first VM, activate the second VM (paragraph 40, “…when a virtual machine experiences a failure and a recovery is needed, retrieves the recovery image ….and restores the virtual machine…create standby instances of the virtual machines…” teaches use of recovery image to restore vm, and in at least some instances the recovery includes a standby instance). This known technique is applicable to the system of Behere and Deshpande as they both share characteristics and capabilities, namely, they are directed to virtual machine management in a networked environment including VM migration.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Chan would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Chan to the teachings of Behere and Deshpande would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine management into similar systems. Further, applying periodic restoration of the standby VM using incremental backup/delta images and activate the standby VM in response to a failure of first VM to Behere and Deshpande with performing successive incremental backup operations to generate incremental backup copies of the first primary data, restoring the first backup copy and one or more of the incremental backup copies into second primary data, wherein the second primary data is stored in a second data storage resource that is configured in the cloud computing environment , and activating a virtual machine in a cloud computing environment uses the second primary data from the second data storage resource as a source of primary data for the virtual machine accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow reduced downtime and improved speed of recovery of VM failure. (Chan, paragraph 4 and 6).
As for claim 2, Deshpande teaches restoring a given incremental backup copy is performed asynchronously with generating the given incremental backup copy (paragraph 172-173).
As for claim 3, Deshpande also teaches the first virtual machine server operates in a non-cloud environment (paragraph 61 teaching the virtual machines can be implemented in either cloud or non-cloud environment).
In addition, Behere also teaches the above claim limitation (paragraph 22, “…hardware platform…” and paragraph 8, “…maybe hosted in a …Data ONTAP storage virtual machine…”);
As for claim 4, Deshpande also teaches the first virtual machine server operates in the cloud computing environment of the second virtual machine (paragraph 61 teaching the virtual machines can be implemented in either cloud or non-cloud environment).
In addition, Behere also teaches the above claim limitation (paragraph 22, “…hardware platform…” and paragraph 8, “…maybe hosted in a …Data ONTAP storage virtual machine…” Examiner note, it is well-known in the art ONTAP storage virtual machine can operate in the cloud environment. See, e.g., Kevin Hill, “NetApp Cloud: Cloud ONTAP for amazon Web Services”, community.netapp.com/t5/Tech-ONTAP-Articles/NetApp-Cloud-Cloud-ONTAP-for-Amazon-Web-Services/ta-p/92693, 11/12/2014).
As for claim 6, Chan also teaches a plurality of the incremental backup copies are consolidated into a consolidated copy (paragraph 40); and
wherein the plurality of the incremental backup copies are restored by restoring the consolidated copy to the second data storage resource (paragraph 40).
As for claim 9, Deshpande teaches that the migration of virtual machine data to a new hardware can be based on detection of hardware failure executing the virtual machine (paragraph 220).
In addition, Chan teaches the second virtual machine is activated based on detecting that the first virtual machine has failed (paragraph 40). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Chan because doing so would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved speed in error recovery of a virtual machine. (Chan, paragraphs 4 and 6).
As for claim 10, Behere also teaches the second data storage resource is configured as a data store for the second virtual machine (paragraph 57, “.destination disk directory at which converted data from the source VM will be stored…”).
As for claim 11, Behere teaches a computer-implemented method comprising:
generating a first backup copy of first primary data of a first virtual machine (In a first embodiment, paragraph 37, “…store a source VM virtual disk…arrangement of blocks corresponding to a virtual disk format used by the source hypervisor…”, paragraph 38, “…each of the source VM virtual disk….may have one or more blocks dedicated to storage of data and metadata…” paragraph 40, “…prior to migration, the data for the VMs…” teaches the creation of the source VM virtual disk stored inside a data storage 112/ONTAP storage cluster. In an alternative embodiment, paragraph 58, “…generated destination disks…” teaches based on source VM virtual disk, generating a destination disks capable of being used to create a destination VM, thus, the destination disks generated, but before actual use by destination VM, is also a form of backup disk that corresponds to the source VM),
wherein the first virtual machine is hosted by a first hypervisor operating on a first virtual machine server, which comprises one or more hardware processors and computer memory (paragraph 32, “…source VM managed by a source hypervisor…” in view of paragraph 22, “…execution environment platform 108 …abstracts a hardware platform…providing of the virtual machine performed by a hypervisor 110…runs on an actual hardware platform…” and paragraph 63, “…common computing elements, such as one or more processors…memory units…”),
wherein the first backup copy comprises one or more configuration parameters of the first virtual machine (paragraph 38, “each of the …virtual disk…may have one or more blocks dedicated to storage of data and metadata used by the …hypervisor….for managing its access to the common blocks…” the data and metadata are understood as forms of configuration parameters related to the management of blocks within the virtual disks (source VM virtual disk and/or copied to and created destination VM virtual disk in view of above mappings) are clearly for managing the common blocks, which is understood as a form of configuration parameter. In an alternative embodiment, paragraph 46-49, “for migrating a vm….a configuration maybe established …using configuration cmdlets…specify details of the source hypervisors..VMs..guest OS, and/or storage components…as well as details regarding the network configuration of the source VM…may include an NIC-to-MAC mapping…include locations of any storage resources used by the source VM…” configuration information generated and associated with the source VM virtual disk to be migrated can be understood as claimed configuration parameters as well.);
by a first computing resource, obtaining, from the first backup copy, the one or more configuration parameters of the first virtual machine (First embodiment, paragraph 53-54, “…configuration maybe established…convert command may specify a name of a VM, as well as a direction of conversion…utilize …the configuration information…” teaches obtaining the configuration information and converting it, to convert it would obviously require obtaining the configuration information to convert from. Second embodiment, paragraph 57, “discovers …data from the source VM….calls the disk conversion library to convert the source VM data into a format compatible with …”in view of paragraph 38, “virtual disk may have one or more blocks dedicated to storage of data and metadata used by the source hypervisor….not accessible to the guest OS…for managing its access to the common blocks…” teaches a different set of configuration information of the source VM that is accessed and configured. teaches converting (which clearly includes obtaining) the source VM data);
by the first computing resource, causing a second virtual machine to be configured in a computing environment, wherein configuring the second virtual machine comprises converting the one or more configuration parameters into a format suitable for the cloud computing environment (First embodiment, paragraph 53-54, “…configuration maybe established…convert command may specify a name of a VM, as well as a direction of conversion…utilize …the configuration information…” teaches obtaining the configuration information and converting it. Second embodiment, paragraph 57, “discovers …data from the source VM….calls the disk conversion library to convert the source VM data into a format compatible with …”in view of paragraph 38, “virtual disk may have one or more blocks dedicated to storage of data and metadata used by the source hypervisor….not accessible to the guest OS…for managing its access to the common blocks…” teaches a different set of configuration information of the source VM that is accessed and configured. teaches the source VM data that includes configuration data. Paragraph 57-58, “converted data from the source VM …stored…calls the disk conversion library to convert the source VM data into a format compatible with the destination VM disk type…generated destination disks …creates a new VM using the generated destination disks at step 420…” and paragraphs 52-54, “…VM configuration…list of virtual disks with backend storage locations…NIC cards associated with the VM; and a disk driver mapping, among other…convert command may utilize…the configuration information …” in view of paragraph 58 teaches use of converted parameters and disks containing the parameters are used as part of configure/create the second/destination VM);
activating the second virtual machine, wherein the activated second virtual machine uses the first primary data from the first data storage resource [destination path] as a source of primary data for the second virtual machine (paragraph 57, migration server …calls the Disk Conversion Library to convert the source VM data into a format compatible with the destination VM disk type…paragraph 58, “…creates a VM using the generated destination disk at step 420”).
Deshpande teaches a known method of virtual machine migration/backup/archiving/restoration in a networked environment including virtual machine executing in a cloud computing environment (paragraph 61) performing successive incremental backup operations to generate incremental backup copies of the first primary data (paragraph 170-172, “…incremental backup operation…tracks and stores changes that have occurred since the last full backup…”)
restoring the first backup copy and one or more of the incremental backup copies into second primary data, wherein the second primary data is stored in a second data storage resource that is configured in the cloud computing environment (paragraph 168-172, “…backup operation creates a copy of primary data….subsequent backup copy maybe maintained independently of the first incremental backup operation…restore operation …involve accessing a full backup in addition to …incremental backup…”);
the migration of virtual machine data to a new hardware can be based on detection of hardware failure executing the virtual machine (paragraph 220); and
Activating a virtual machine uses the second primary data from the second data storage resource as a source of primary data for the virtual machine (paragraph 291, 295, 297, 305, 307). This known technique is applicable to the system of Behere as they both share characteristics and capabilities, namely, they are directed to virtual machine management in a networked environment including VM migration.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Deshpande would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Deshpande to the teachings of Behere would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine management into similar systems. Further, applying performing successive incremental backup operations to generate incremental backup copies of the first primary data, restoring the first backup copy and one or more of the incremental backup copies into second primary data, wherein the second primary data is stored in a second data storage resource that is configured in the cloud computing environment , and activating a virtual machine in a cloud computing environment uses the second primary data from the second data storage resource as a source of primary data for the virtual machine to Behere with backing up copy of a first virtual machine, and restoring the backed up copy into a second virtual machine accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow reduced storage requirements for dynamic and continuous virtual machine backups. (Deshpande, paragraph 172).
Chan teaches restoring the first backup copy and each successive incremental backup copy is performed periodically to maintain the second VM in a synchronized non-executing warm-standby state updated by on the incremental backup copies (paragraph 40) and the second virtual machine is activated based on detecting that the first virtual machine has failed (paragraph 40). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Javadekar because doing so would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved speed in error recovery of a virtual machine. (Chan, paragraphs 4 and 6).
As for claim 12, Chan also teaches the first backup copy and the successive incremental backup copies are generated at least in part by a first data agent that is associated with the first virtual machine server (paragraph 40 and Fig. 4 – Snapshot agent).
As for claim 15, Chan also teaches the first backup copy and the successive incremental backup copies are generated at least in part by a first data agent associated with the first virtual machine server and by a first media agent, and wherein the first data agent and the first media agent execute on one or more computing devices comprising one or more processors and computer memory (paragraph 40, Examiner note, the first data agent and first media agent are understood as functionalities performed. each functionality is understood as be implemented by sequences of instructions implementing said different functionalities and functionally an “agent”).
As for claim 19, Behere also teaches the first hypervisor is of a first type and the second hypervisor is of a different type (paragraph 11, “…conversion …convert the virtual machine from the first type of hypervisor to the second type of hypervisor…”).
As for claim 20, Deshpande also teaches the second virtual machine is implemented as a cloud computing resource in a cloud computing environment (paragraph 61).
Claim(s) 5 is rejected under 35 U.S.C. 103 as being unpatentable over Behere, Deshpande, and Chan, in view of Tarasuk-Levin et al. (US PGPUB 2017/0060628).
As for claim 5, while Behere, Deshpande and Chan teaches the hosting environment of the virtual machines can be arbitrarily cloud based or non-cloud based. In the interest of compact prosecution, Examiner note Behere, Deshpande and Chan do not explicitly teach both the source and destination VMs are in two different clouds.
However, Tarasuk-Levin teaches a known method of VM migration including the first virtual machine server operates in a cloud computing environment that is different from the cloud computing environment of the second virtual machine (paragraphs 26-27 in view of paragraph 2). This known technique is applicable to the system of Behere, Deshpande and Chan as they both share characteristics and capabilities, namely, they are directed to virtual machine management in a networked environment including VM migration.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Tarasuk-Levin would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Tarasuk-Levin to the teachings of Behere, Deshpande and Chan would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine management into similar systems. Further, applying VM migration from first VM server in a first cloud to a second VM server in a second cloud different from the first to Behere, Deshpande and Chan with VM migration from a first host to a second host where the first and/or second host can be implemented in cloud or servers accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved support for VM migration between on-premise datacenter/private cloud to a public cloud. (Tarasuk-Levin, paragraph 2).
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Behere, Deshpande and Chan, in further view of Vick et al. (US PGPUB 2010/153662).
As for claim 7, Behere, Deshpande and Chan do not explicitly teach restoration of incremental backup copies based on threshold and use older copy to restore the VM in response to exceeding threshold attempts.
However, Vick teaches a known method of virtual machine checkpointing and restoration for fault-tolerance including based on detecting that restoring a first one of the incremental backup copies has failed more than a threshold number of times: (i) causing a second one of the incremental backup copies [safepoint], which is older than the first one of the incremental backup copies, to be restored to the second data storage resource, and (ii) blocking any further restore operations to the second data storage resource (paragraph 64 in view of 63, teaching the use of safepoint to restore virtual machine state in contrast to the later checkpoints in response to specific exceptions. Here, Examiner note, threshold can be understood as occurrence of any condition that occurred once). This known technique is applicable to the system of Behere, Deshpande and Chan as they both share characteristics and capabilities, namely, they are directed to virtual machine management in a networked environment including VM state restoration.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Vick would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Vick to the teachings of Behere, Deshpande and Chan would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine management into similar systems. Further, applying using earlier checkpointed copies in response to specific condition occurring threshold number of times to Behere, Deshpande and Chan with VM state restoration using different incremental copies accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow specific handling of error conditions encounter in VM execution by restoring different points/values in a workload executing in virtual machine. (Vick, paragraph 7 and paragraph 64).
Claim(s) 8, 13 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Behere, Deshpande and Chan, in further view of Javadekar et al. (US PGPUB 2015/0154081).
As for claim 8, while Behere’s the source and destination hosts clearly perform functionalities for the backup and restore of the VM data respectively, and while Chan teaches snapshot agent to generate first backup copy and incremental backup copies, and clearly there is software functionality at the standby VM instance’s location to restore/start the standby instance in response to failure, in the interest of compact prosecution, Examiner note Behere, Deshpande and Chan do not explicitly teach Existence of both a first data agent and a first media agent and a second data agent and a second media agent distinct from the first.
However, Javadekar teaches a known method of virtual machine incremental checkpointing including a first data agent and a first media agent are configured to generate the first backup copy and the incremental backup copies (paragraphs 23-25); and wherein a second data agent and a second media agent, which are distinct from the first data agent and the first media agent, respectively, are configured to restore the first backup copy and the one or more of the incremental backup copies (paragraphs 26-28). This known technique is applicable to the system of Behere, Deshpande and Chan as they both share characteristics and capabilities, namely, they are directed to virtual machine management in a networked environment including VM migration using incremental checkpointing.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Javadekar would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Javadekar to the teachings of Behere, Deshpande and Chan would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine management into similar systems. Further, applying first data and media agents performing backup and second data/media agents performing restoring to Behere, Deshpande and Chan with VM migration functionalities performed at both source and destination execution environments accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved speed in error recovery of a virtual machine. (Javadekar, paragraph 2).
As for claim 13, Javadekar both teaches the first data agent obtains the one or more configuration parameters [state] of the first virtual machine from the first virtual machine server (Javadekar, Fig. 2 – Incremental Checkpoint Module 204 and paragraph 24). Refer to claim 8 for the motivation to combine.
As for claim 17, Chan also teaches by a first media agent that executes on a computing device comprising one or more processors and computer memory, storing the first backup copy and the successive incremental backup copies in a first secondary data storage device (paragraph 40); and
Javadekar also teaches by the first media agent, transmitting the first backup copy and the successive incremental backup copies to a second media agent that executes on a computing device comprising one or more processors and computer memory, for storage at a second secondary data storage device (paragraph 23 and 25, “….transmits the snapshot to backup computer system 210…transmit any data for disk writes made by primary VM 202 …”), wherein the first backup copy and the successive incremental backup copies are restored from the second secondary data storage device to the second data storage device that is communicatively coupled to the second virtual machine server (paragraph 21, “incremental checkpoint module 214 ultimately receives each of the transmitted checkpoint information …updates the state of the memory and emulated devices of backup VM 212…” and paragraph 27-28, “…incremental checkpoint module 214 may commit to the virtual disk…all disk write data received…merges the updated state into the current state of backup VM….modify the state data of backup VM….based on received checkpoint information…”). Refer to claim 8 for the motivation to combine.
As for claim 18, Chan also teaches a first data agent and a first media agent are configured to generate the first backup copy and the successive incremental backup copies (paragraph 40 and Fig. 4); and
Javadekar also teaches wherein a second data agent and a second media agent, which are distinct from the first data agent and the first media agent, respectively, are configured to restore the first backup copy and each successive incremental backup copy to the second data storage device that is communicatively coupled to the second virtual machine server (paragraph 27-28). Refer to claim 8 for the motivation to combine.
Claim(s) 14 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Behere, Deshpande and Chan, in further view of Lassonde et al. (US PGPUB 2011/0010708).
As for claim 14, while Behere teaches converting a configuration of VM from source hypervisor understood format to a destination hypervisor understood format, Behere, Deshpande and Chan do not explicitly teach the conversion into a hypervisor-independent format first.
However, Lassonde teaches a method of migration of workload executing in a virtual machine from one source machine to destination machine including the one or more configuration parameters [configuration settings] are included in the first backup copy in a hypervisor-independent format, and wherein the first data agent converts the one or more configuration parameters into the hypervisor-independent format (Abstract, “….transformed into a platform and application independent format before being transferred to a target machine…” in view of paragraph 13, “…machines include …virtual machines that maybe hosted on a virtual server 17…”). This known technique is applicable to the system of Behere, Deshpande and Chan as they both share characteristics and capabilities, namely, they are directed to virtual machine management in a networked environment including VM migration and configuration conversion.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Lassonde would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Lassonde to the teachings of Behere, Deshpande and Chan would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine management into similar systems. Further, applying conversion of source machine configuration parameters to an independent format before converting to a destination specific format to Behere, Deshpande and Chan with VM migration functionalities including conversion of configuration parameters from source hypervisor specific format to destination hypervisor specific format accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved migration of workload to implement different non-standardized configurations. (Lassonde, paragraph 2).
As for claim 16, Lassonde also teaches the first data agent converts the one or more configuration parameters into a hypervisor-independent format, and wherein the first media agent includes the one or more configuration parameters, in the hypervisor-independent format, into the first backup copy (Abstract).
This known technique is applicable to the system of Behere, Deshpande and Chan as they both share characteristics and capabilities, namely, they are directed to virtual machine management in a networked environment including VM migration and configuration conversion.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Lassonde would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Lassonde to the teachings of Behere, Deshpande and Chan would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such virtual machine management into similar systems. Further, applying the first data agent converts the one or more configuration parameters into a hypervisor-independent format, and wherein the first media agent includes the one or more configuration parameters, in the hypervisor-independent format, into the first backup copy to Behere, Deshpande and Chan with VM migration functionalities including conversion of configuration parameters from source hypervisor specific format to destination hypervisor specific format accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved migration of workload to implement different non-standardized configurations. (Lassonde, paragraph 2).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached M-F 10am-6pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached on 5712723759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197
(toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KEVIN X LU/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199