DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 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.
Claims 1, 4-8, 11-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Coady et al. (US PGPUB 2019/0347127) in view of Vohra (US PGPUB 2024/0211276), Luo et al. (US PGPUB 2023/0221877), Kashi Visvanathan (US PGPUB 2023/0409535; hereinafter “Kashi”) and Ofek et al. (US Patent 5,680,640).
With regard to Claim 1, Coady teaches a method for migrating virtual machine snapshots to application container platforms, the method comprising:
migrating, from a virtual machine platform to a volume on a container platform ([0001] “The present disclosure is generally related to migrating computing services from a hardware level virtualization platform using virtual machines to an operating system level virtualization platform using containers.” [0016] “The conversion process may receive input identifying one or more virtual machines and may iterate through each virtual machine and migrate the services of each virtual machine to corresponding containers.” [0026] “The operating system level virtualization may provide a pool of computing resources that are accessible by container 125A… The pool of resources may include filesystem resources (e.g., particular volumes).”), and
a base disk file associated with a virtual machine ([0047] “identify a mapping of virtual machine operating systems (i.e. kernels) to available base images for building container images.” [0048] “the service rules may identify the kernel used on the virtual machine environment that the given process runs on, and a base image that corresponds to the kernel that can be used in building the container images.” [0091] “The parent container image may include a base image corresponding to a guest operating system of the virtual machine.”).
With further regard to claim 1, Coady does not teach the migration utilizing a common storage class as described in claim 1. Vohra teaches
migrating utilizing a common storage class ([0422] “a CSI filter driver may be configured to facilitate migration from non-containerized applications (e.g., virtual machine (VM) applications, such as VMWare applications, or any other type of legacy application) to containerized applications. In particular, the CSI filter driver may allow a legacy storage system used by a non-containerized application to also be used by a containerized application. This may allow a non-containerized application to be migrated to a containerized application while still retaining legacy storage system functionality (e.g., legacy storage policy management, storage class translation, etc.),” wherein the disclosure regarding the retaining of legacy “storage class” functionality teaches the above claim language.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the method as disclosed by Coady with the migration utilizing a common storage class by Vohra in order “to facilitate a serverless, cloud native computing deployment and management model for software applications” (Vohra [0195]).
With further regard to claim 1, Coady in view of Vohra does not teach the delta file as described in claim 1. Luo teaches
the base disk file having at least one delta disk file associated therewith, each delta disk file recording changes made to the virtual machine after a snapshot was taken ([0030] “FIG. 3 illustrates a branch 300 of a native snapshot hierarchy in a second object store… However, first set of data 310 may correspond to data of a base vmdk file (e.g., y.vmdk), second set of data may correspond to data of a first delta file (e.g., y-delta1.vmdk file).” [0036] “After the snapshot, a new y-delta3.vmdk 522 is created and the y-delta3.vmdk 522 now becomes the object running point.”);
after migrating the base disk file, repeatedly performing the following for each delta disk file:
take a snapshot of the volume on the container platform (Abstract of Luo: “After the migrating, the example method includes instructing to take a first native snapshot on the object running point in the second object store.” [0047] “after the first chain copy operation for disk chain 410… in block 640 ‘instruct to take snapshot on object running point,’ management entity 160 is configured to instruct host-C 110C to take a snapshot on the object running point.”);
migrate the delta disk file from the virtual machine platform to the container platform; and write the delta disk file to the volume ([0040] “FIG. 6 is a flow diagram of an example process 600 to migrate a VM and its snapshot hierarchy having a plurality of branches from a first object store to a second object store.” [0041] “management entity 160 is configured to identify the disk chain including the ‘You Are Here’ disk in snapshot hierarchy 400, which is disk chain 420... Management entity 160 is configured to migrate this identified disk chain (e.g., first disk chain).” [0031] “First disk chain 410 includes a parent disk 411, a first child disk 412 and a second child disk 413.” [0032] “data on first child disk 412 may be saved in a file of x-delta1.vmdk… data on second child disk 413 may be saved in a file of x-delta2.vmdk.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the method as disclosed by Coady in view of Vohra with the snapshot and delta file as taught by Luo thereby enabling a method “to migrate a VM and its snapshot hierarchy having a plurality of branches from a first object store to a second object store” (Luo [0012]).
With further regard to claim 1, Coady in view of Vohra and Luo does not teach the assigning the delta file to a task based on a task queue as described in claim 1. Kashi teaches
wherein writing the delta disk file comprises assigning the delta disk file to a task, in parallel, based on a task queue ([0051] “a file storage service generates deltas between snapshots in a source file system, and transfers the deltas and associated data through a high-throughput object storage to recreate a new snapshot in a target file system located in a different region during disaster recovery.” [0111] “the tasks (or replication jobs).” [0208] “the target CP may enqueue target side replication jobs (e.g., delta application) into the target replication job queue 1510.” [0187] “each thread in the thread pool wakes up periodically and picks a job from the fair-share queue 1340 if it exists, or from an internal queue (1322a-n) of queue-of-queue 1320 in a round-robin fashion. In other words, the first thread may pick up a job from internal queue 1 (1322a). The second thread may pick up another job from internal queue 2 (1322b), and so on. In some embodiments, all the threads in the thread pool execute their jobs in parallel, concurrently, and independently.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the method as disclosed by Coady in view of Vohra and Luo with the assigning the delta file to a task based on a task queue as taught by Kashi such that “no bottleneck exists, and both the parallelism and fair-share resource utilization among threads executing jobs are maintained… resources are available for each replication-related job, distributed evenly (or uniformly) to all replication-related jobs, while constraints are in place to prevent potential resource starvation in any pipelines” (Kashi [0179]).
With further regard to claim 1, Coady in view of Vohra, Luo and Kashi does not teach the flag value which indicates that data needs to be migrated as described in claim 1. Ofek teaches
wherein writing the delta disk file comprises marking the delta disk file with a flag value; wherein the flag value determines whether the delta disk file needs to be migrated (Col. 7 Ln. 50-57: “the data map/table 24 which is one feature of the present invention includes... other flag bits 62 such as... an indication of whether or not data on a particular device, volume or track needs migration or has been migrated from the first to the second data storage system 14/16 respectively, as shown generally by flag or indicator bit 60,” see also Fig. 2 showing “Indicator Bit 60” as indicating that the associated data “Needs Migration”.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the method as disclosed by Coady in view of Vohra, Luo and Kashi with the flag value which indicates that data needs to be migrated as taught by Ofek in order “ to determine whether or not a particular track or record which has been requested is write-pending or has been migrated to the second system” (Ofek Col. 7 Ln. 16-19).
With regard to Claim 4, Coady in view of Vohra, Luo, Kashi and Ofek teaches all the limitations of Claim 1 as described above. Luo further teaches wherein the base disk file is a base VMDK (Virtual Machine Disk) file ([0030] “first set of data 310 may correspond to data of a base vmdk file (e.g., y.vmdk).”).
With regard to Claim 5, Coady in view of Vohra, Luo, Kashi and Ofek teaches all the limitations of Claim 1 as described above. Luo further teaches wherein the delta disk files are delta VMDK files ([0030] “second set of data may correspond to data of a first delta file (e.g., y-delta1.vmdk file) and third set of data may correspond to data of a second delta file (e.g., y-delta2.vmdk file).”).
With regard to Claim 6, Coady in view of Vohra, Luo, Kashi and Ofek teaches all the limitations of Claim 1 as described above. Luo teaches further comprising verifying that the volume supports snapshots in the container platform ([0025] “Object store 152 may support a first snapshot implementation and object store 154 may support a second snapshot implementation. The first snapshot implementation may be the redo log snapshot implementation and the second snapshot implementation may be the native snapshot implementation.” [0036] “The first chain copy operation may include a second step of creating a native snapshot on y.vmdk 511 because the second object store is configured to support native snapshots”).
With regard to Claim 7, Coady in view of Vohra, Luo, Kashi and Ofek teaches all the limitations of Claim 1 as described above. Luo further teaches wherein the delta disk files are written to the volume in an order in which they were created on the virtual machine ([0027] “x.vmdk, x-delta1.vmdk and x.delta2.vmdk may correspond to objects 211, 221 and 231 in the first object store, respectively.” [0034] “the first chain copy operation includes copying chain 420 from the first object store to form chain 520 in the second object store.” [0035] “The first chain copy operation may include a first step of creating y.vmdk 511 in the second object store and copying data of x.vmdk 411 to y.vmdk 511.” [0045] “The second step also includes copying data of x-delta1.vmdk 412 to y-delta1.vmdk 512.” [0046] “The third step also includes copying data of x-delta2.vmdk 413 to y-delta2.vmdk 513. Block 630 may be followed by block 640.”).
With regard to Claims 8 and 11-14, these claims are equivalent in scope to Claims 1 and 4-7 rejected above, merely having a different independent claim type, and as such Claims 8 and 11-14 are respectively rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1 and 4-7.
With further regard to Claim 8, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Coady reference also anticipates these additional elements of Claim 8, for example, wherein Coady teaches:
A computer program product for migrating virtual machine snapshots to application container platforms, the computer program product comprising a computer- readable storage medium having computer-usable program code embodied therein, the computer-usable program code configured to perform the following when executed by at least one processor ([0078] “it should be appreciated that the methods disclosed in this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such methods to computing devices. The term ‘article of manufacture,’ as used herein, is intended to encompass a computer program accessible from any computer-readable device or storage media.” [0124] “Example 15 is a non-transitory computer-readable medium comprising instructions that, when executed by a processing device of a first computer system, cause the processing device to perform operations comprising…”).
With regard to Claims 15 and 17-20, these claims are equivalent in scope to Claims 1 and 4-7 rejected above, merely having a different independent claim type, and as such Claims 15 and 17-20 are respectively rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1 and 4-7.
With further regard to Claim 15, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Coady reference also anticipates these additional elements of Claim 15, for example, wherein Coady teaches:
A system for migrating virtual machine snapshots to application container platforms, the system comprising: at least one processor; at least one memory device operably coupled to the at least one processor and storing instructions for execution on the at least one processor, the instructions causing the at least one processor to ([0077] “Methods 400, 500, and 600 may be performed by processing devices that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), executable code (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.” [0094] “the apparatus 700 may include processing device 710 that may execute instructions for carrying out the operations of the apparatus 700 as discussed herein.” [0116] “Example 8 is system comprising: a memory; a processing device operatively coupled to the memory, the processing device to…”).
Claims 2-3, 9-10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Coady in view of Vohra, Luo, Kashi and Ofek as applied to Claims 1, 8 and 15 above, and further in view of Shaw et al. (US PGPUB/20240134822).
With regard to claim 2, Coady in view of Vohra, Luo, Kashi and Ofek teaches all the limitations of claim 1 as described above. Coady in view of Vohra, Luo, Kashi and Ofek does not teach the migration marking as described in claim 2. Shaw teaches
wherein writing the delta disk file to the volume further comprises marking the delta disk file as migrated from the virtual machine platform to the container platform ([0053] “the cloud platform migration engine 112 makes a determination whether the contents of all objects from a source cloud storage platform corresponding to all base and delta snapshots for the block repository task have been sent to the second cloud storage platform. Responsive to an affirmative determination, the snapshots are flagged as ready to restore from the destination cloud storage platform. The operational flow 200 is then ended at block 213,” wherein the “flag”, i.e. “marking”, is the indicator bit flag as taught above in Ofek.).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to have modified the method as disclosed by Coady in view of Vohra, Luo, Kashi and Ofek with the migration marking as taught by Shaw in order to “advantageously enable users to utilize a CTA or other migration appliance to migrate snapshots between cloud storage platform” (Shaw [0082]).
With regard to Claim 3, Coady in view of Vohra, Luo, Kashi and Shaw teaches all the limitations of Claim 2 as described above. Shaw further teaches wherein marking the delta disk file as migrated comprises setting a flag associated with the delta disk file ([0053] “the cloud platform migration engine 112 makes a determination whether the contents of all objects from a source cloud storage platform corresponding to all base and delta snapshots for the block repository task have been sent to the second cloud storage platform. Responsive to an affirmative determination, the snapshots are flagged as ready to restore from the destination cloud storage platform. The operational flow 200 is then ended at block 213,” wherein the “flag”, i.e. “marking”, is the indicator bit flag as taught above in Ofek.).
With regard to Claims 9-10, these claims are equivalent in scope to Claims 2-3 rejected above, merely having a different independent claim type, and as such Claims 9-10 are respectively rejected under the same grounds and for the same reasons as discussed above with regard to Claims 2-3.
With regard to Claim 16, this claim is equivalent in scope to Claim 2 rejected above, merely having a different independent claim type, and as such Claim 16 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 2.
Response to Arguments
Applicant's arguments, see Pages 9-10 of the Remarks filed 8/21/2025, with respect to the rejections under 35 U.S.C. 103 of Claims 1-20 have been fully considered but they are not persuasive. With respect to the Applicant’s argument that the newly amended language of Claims 1, 8 and 15 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Ofek et al. (US Patent 5,680,640) reference as discussed above in the respective rejections.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Kachare et al. (US PGPUB 2021/0263762) discloses a method and system for improving the migration of virtual machines (VMs) from one server to another, including various flags which indicate the state of various VM migration related operations, such as a ‘VM migration active’ flag which indicates that the associated data is being prepared to be migrated.
Karki et al. (“Enforcing End-to-End I/O Policies for Scientific Workflows Using Software-Defined Storage Resource Enclaves,” 2018) discusses the design and implementation of a data management infrastructure called Software-Defined Storage Resource Enclaves (SIREN) at the system level to enforce end-to-end policies that dictate an I/O pipeline’s performance, wherein SIREN includes the use of a migration flag to indicate data which needs to be migrated.
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 NICHOLAS J SIMONETTI whose telephone number is (571)270-7702. The examiner can normally be reached Monday-Thursday 10AM-6PM EST.
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, Arpan Savla can be reached at (571) 272-1077. 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.
/NICHOLAS J SIMONETTI/ Primary Examiner, Art Unit 2137 November 29, 2025
Prosecution Insights