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 Applicant Amendment and Arguments filed on 12 February, 2026.
Claims 1-22 are pending for examination.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5, 7-10, 13, 15-17, 20 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Blake (US Pub. 2015/0067390 A1) in view of Wang et al. (US Patent. 8,849,876 B2) and further in view of Hutcheson et al. (US Pub. 2020/0159625 A1) and Bushman (US Patent. 9,727,264 B1).
Blake, Wang, Hutcheson and Bushman were cited in the precious Office Action.
As per claim 1, Blake teaches the invention substantially as claimed including one or more non-transitory computer-readable media storing program instructions that, when executed by one or more processors, cause the one or more processors to perform steps of (Blake, Claim 13, A non-transitory computer-readable storage medium having instructions that, when executed by a processing device, cause the processing device to perform operations):
in a persistent memory, one or more areas [allocated] associated with a virtual memory (Blake, Fig. 1, 117 storage device (as persistent memory), 129 live snapshot area (as one or more areas that is allocated for storing the live snapshot), 115 memory, 103 virtual machine; [0017] lines 1-3, The host computer system 101 may also be coupled to one or more storage devices 117 via a direct connection; [0027] lines 4-6, The VM includes a memory (as virtual memory) and an original disk file that the VM can use to perform disk (e.g., I/O) operations; Fig. 2, 202 receive a request to create a live snapshot of a state of a virtual machine at a reference point-in-time, 204; [Examiner noted: the storage device coupled to the host computer system which including the virtual machine memory, and the live snapshot of the virtual memory is stored within an area of storage device (as one or more areas of persistent memory), thus, that one or more areas is associated with the virtual memory (i.e., snapshot of the virtual machine memory); also see [0019] saved memory state]);
copying the first portion into the one or more areas in the persistent memory in the first pass without pausing a virtual machine to which the virtual memory is allocated (Blake, Fig. 1, 129 live snapshot, 121 and 127; [0008] lines 10-13, Snapshots can preserve the state of a VM by creating a record of the VM's operating system, disks, memory, and application at a given point in time. Snapshots can be taken at various points in time (as include first pass, i.e., first point-in time) by generating a copy of the memory (as include first portion), since the virtual machine is keep executing, the memory will be keep modified); [0011] lines 1-21, Aspects of the present disclosure address these shortcomings by providing techniques for creating a consistent and reliable snapshot without any VM downtime. A hypervisor creates an overlay disk file to copy data from an original disk file at a reference point in time. The overlay disk file is another disk file that contains the state of the original disk file at the reference point in time…In addition, the hypervisor can create a memory snapshot at the reference point-in-time. The copy of the memory can be generated by copying a process that is executing the VM, which also includes the memory of the VM…The live snapshot is now complete and includes the overlay disk file and the memory snapshot; [0021] lines 30-32, the snapshot manager 108 can use the child process memory 127 for the live snapshot 129. In this manner a live snapshot 129 is provided without VM 103 downtime; also see [0027] lines 1-7, at block 202, with the hypervisor receiving a request to create a live snapshot of a state of a VM at a reference point in time. The VM includes a memory (as virtual memory is allocated) and an original disk file that the VM can use to perform disk (e.g., I/O) operations; [also see [0030] lines 2-9, with the hypervisor issuing a fork system call to replicate a parent process associated with the VM memory at a reference point in time. The hypervisor can issue the fork system call in response to receiving a request to take a snapshot. As a result of the fork system call, the memory of the VM (the original or "parent" process running the VM) can be marked as shared, and a new (child) process can be created with the same view of the shared memory; [0031] lines 1-13, the hypervisor freezes the child process associated with child memory that corresponds to the shared memory to preserve the state of the memory at the reference point in time. When the child process is frozen, there is no activity (e.g., read/write operations) to the child memory. As to the parent process, if the parent process attempts to write into a page of memory that is still shared by the parent and child, then the memory is changed to no longer be shared, causing the parent process to write to its own memory for that page of memory. At block 306, the child memory is dumped to a destination storage to form a memory snapshot. The memory snapshot can be used to create a live snapshot at the reference point in time]);
the first portion for copying in a second pass subsequent to the first pass without pausing the virtual machine (Blake, Fig. 1, 129 live snapshot; [0008] lines 10-13, Snapshots can preserve the state of a VM by creating a record of the VM's operating system, disks, memory, and application at a given point in time. Snapshots can be taken at various points in time (as include second pass that is subsequent to the first pass, i.e., after first point-in time), since the virtual machine is keep executing, the portion of the memory (i.e., first portion) will be keep modified); see [0009] lines 1-8, As a VM executes operations, it can make changes to data (e.g., memory, stored data, code) associated with the VM (as include applying the write request to the first portion). Changes to the data can come in the form of software updates that can be applied to the VM and to applications that are executed by the VM. Sometimes, changes to the data can cause problems with the VM. The hypervisor can perform a rollback to restore the VM to a previous state captured in the snapshot as if the changes to the data had never happened; also see [0021] lines 21-32, When the VM 103 attempts to modify a page of shared memory, that portion of shared memory is updated to no longer be shared, causing the VM 103 to write to its own memory for that memory page. Meanwhile, the snapshot manager 108 can perform a memory dump operation to transfer the memory of the child process 133 to the live snapshot 129, in particular to the portion of the live snapshot that captures the child process memory 127. In this implementation, once the transfer of the memory of the child process 133 is complete, the snapshot manager 108 can use the child process memory 127 for the live snapshot 129. In this manner a live snapshot 129 is provided without VM 103 downtime).
Although Blake teaches one or more areas of persistent memory [allocated] for copying the first portion of virtual memory (i.e., to create a memory snapshot), Blake fails to specifically teach the allocated areas are based on allocating, one or more blocks, and when copying into the one or more areas, it is copying into the one or more blocks.
However, Wang teaches the allocated areas are based on allocating, one or more blocks, and when copying into the one or more areas, it is copying into the one or more blocks (Wang, Fig. 1, 109 file system, 113, 115, 117, 119 (as snapshots); Col 4, lines 34-36, storage 101 may store one or more datasets 103 for file system 109 in one or more blocks as basic storage allocation units; Col 4, lines 42-43, clones 113, 115, 117 and live 119, to represent corresponding datasets 103; Col 14, lines 12-14, Claim 7, maintain a plurality of snapshots of data stored in one or more extents of consecutive blocks allocated in a storage (as allocating one or more blocks which is for storing/copying snapshot)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Blake with Wang because Wang’s teaching of storing the snapshot to the allocated consecutive blocks of the storage and managed by the file system would have provided Blake’s system with the advantage and capability to allow the system to easily managing the different snapshots stored within the persistent memory in order to improving the system performance and efficiency (see Wang Col 1, lines 45-50, “impact on the performance of a file system”).
Although, Blake and Wang teach virtual memory and copying the first portion into the one or more blocks in the persistent memory, Blake and Wang fail to specifically teach before copying the first portion, annotating a first portion of the virtual memory for copying in a first pass, receiving a write request associated with the first portion; and in response to receiving the write request: applying the write request to the first portion; and annotating the first portion for copying in a second pass subsequent to the first pass.
However, Hutcheson teaches annotating a first portion of the virtual memory for copying in a first pass (Hutcheson, [0084] lines 4-5, snapshot the data to create a restore point; Fig. 26, virtual machine 2630; Fig. 8A, 801 3, 4, 5, 6, 10, 12, 13, 15 changed while copying, For use in next copy, 810 first incremental copy, first pass copy changed blocks; [0161] lines 7-12, Blocks 3-6, 10, 12-13, 15 changed while copying. As shown at 810, since the full copy phase completed, blocks 3, 4, 7, 14 changed and are added to the list of blocks to copy (as annotating a first portion for copying in a first pass, i.e., changed blocks). During the first pass of the incremental copy, the changed blocks 3-7, 10, 12-15 are copied; please note: virtual memory were taught by Blake); Fig. 8A, 810 first incremental copy, first pass copy changed blocks; copied to backup),
receiving a write request associated with the first portion (Hutcheson, [0057] lines 2-6, receiving, during step (b), an instruction from the operating system to write to a block of the source volume (as write request); and adding an identifier corresponding to the written-to block to a list of modified blocks, wherein step (c) comprises evaluating said list of modified blocks; Fig. 8A, 810, 1, 2, 3, 4, 5, 8, 12, 14, 19, 20 changed while copying (as the write request associated with the first portion), added to changed blocks, For use in next pass;); and
in response to receiving the write request: applying the write request to the first portion (Hutcheson, Fig. 8A, 810, 1, 2, 3, 4, 5, 8, 12, 14, 19, 20 changed while copying, added to changed blocks, For use in next pass; (i.e., due to the write request applied to the blocks (i.e., the blocks in the first portion has been changed) while copying)); and
annotating the first portion for copying in a second pass subsequent to the first pass (Hutcheson, Fig. 8A, 810, 1, 2, 3, 4, 5, 8, 12, 14, 19, 20 changed while copying, added to changed blocks (as including annotating the blocks within the first portion for copying in a second pass), For use in next pass; 820 First incremental copy, second pass copy changed blocks; also see [0102] lines 48-49, marked as changed blocks at the start of a current pass to the designated blocks to copy); [0174] lines 18-19, blocks 1-2, 5, 8, 12 are marked as changed for the next pass).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Blake and Wang with Hutcheson because Hutcheson’s teaching of annotating/marking the portion of the changed blocks for copying in the subsequent pass during the backup/snapshot process would have provided Blake and Wang’s system with the advantage and capability to allow the system to minimize backup completion time which improving the system performance and efficiency (see Hutcheson, [0159] “minimizes backup completion time, usage resource… minimizes the overall number of copy operations”).
Blake, Wang and Hutcheson fail to explicitly teach wherein the first portion is annotated prior to any copying of the first portion for a snapshot.
However, Bushman teaches wherein the first portion is annotated prior to any copying of the first portion for a snapshot (Bushman, Fig. 2, 206 inclusion map; Col 8, lines 49-59, the inclusion map 206 and the inclusion map 216 may be employed to track, at the times indicated, locations in the source storage 108 of content blocks of the files which have been identified for inclusion in the image backups of the source storage 108; Col 10, lines 8-22, The tracking of content blocks of files identified for inclusion in image backups using the inclusion map 206 or the inclusion map 216 may occur prior to the time of a snapshot (as the first portion is annotated (i.e., identified) prior to any copying of the first portion for a snapshot) of the source storage 108 (i.e., “pre-snapshot tracking”) so that the locations of the content blocks are already stored in the inclusion map 206 or the inclusion map 216 at the corresponding snapshot time, enabling the creation of an image backup of the content blocks to commence at the corresponding snapshot time and without the delay that would occur should the locations of the content blocks need to be determined subsequent to the snapshot time. The pre-snapshot tracking in the inclusion map 206 or the inclusion map 216 may reduce the time between the snapshot of the source storage 108 and the completion of the image backup of the source storage 108).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Blake, Wang and Hutcheson with Bushman because Bushman’s teaching of identifying the portion of the content blocks of files within the source storage for pre-snapshot tracking would have provided Blake, Wang and Hutcheson’s system with the advantage and capability to allow the system to enabling the creation of an image backup of the content blocks to commence at the corresponding snapshot time and without the delay that would occur should the locations of the content blocks need to be determined subsequent to the snapshot time.
As per claim 2, Blake, Wang, Hutcheson and Bushman teach the invention according to claim 1 above. Hutcheson further teaches wherein the steps further comprise copying the first portion into the one or more blocks in the persistent memory in the second pass (Hutcheson, Fig. 4B, 403 target volume (as persistent memory); Fig. 8A, 820, First incremental copy, second pass copy changed blocks; Copied to backup; [0161] lines 10-16, During the first pass of the incremental copy, the changed blocks 3-7, 10, 12-15 are copied, resulting in 10 copy operations. Blocks 1-5, 8, 12, 14, 19-20 changed while copying. As shown at 820, during the second pass of the incremental copy, the changed blocks 1-5, 8, 12, 14, 19-20 are copied, resulting in 10 copy operations).
As per claim 5, Blake, Wang, Hutcheson and Bushman teach the invention according to claim 1 above. Hutcheson further teaches wherein the steps further comprise: receiving a write request associated with a second portion of the virtual memory, wherein the second portion is annotated for copying in the first pass and applying the write request to the second portion (Hutcheson, Fig. 8A, 810 First incremental copy, first pass copy changed blocks, changed blocks, 3, 4, 7, 14 changed (as second portion changed after applying the write request) since the first phase, add to changed blocks Blocks_to_copy (i.e., second portion is annotated for copying in the first pass); also see [0057] lines 2-6, receiving, during step (b), an instruction from the operating system to write to a block of the source volume (as write request); and adding an identifier corresponding to the written-to block to a list of modified blocks, wherein step (c) comprises evaluating said list of modified blocks).
As per claim 7, Blake, Wang, Hutcheson and Bushman teach the invention according to claim 1 above. Hutcheson further teaches wherein the steps further comprise, in response to determining that at least one portion of the virtual memory is annotated, copying the at least one portion of the virtual memory into the persistent memory in a subsequent pass (Hutcheson, Fig. 8B, Data blocks change while copying, 3, 4 change frequently, hold off copying until later pass (as subsequent pass); 840, copied to backup, (only 3, 4 blocks are not copied (annotated to not copy due to change frequently, and hold off until later pass), 850, first pass, copied to backup, changed blocks for use in next pass, 860 second pass, and 870 final pass, copied to backup).
As per claim 8, Blake, Wang, Hutcheson and Bushman teach the invention according to claim 1 above. Hutcheson further teaches wherein the steps further comprise, in response to determining that no portion of the virtual memory is annotated, ceasing copying of the virtual memory into the persistent memory (Hutcheson, Fig. 10A, 1001 changed blocks for use in next copy, 1010 changed blocks in next pass in the first pass, 1020 changed blocks, 3, 4, 20 for copy, 1030 final pass, copied to backup, [Examiner noted: 3, 4, and 20 are the final step copied to backup, and there is no more changed blocks for use in next pass. Therefore, no portion of the virtual memory is annotated (i.e., added to the changed blocks), and copying is stopped/ceasing (i.e., final pass)]; please note virtual memory was taught by Blake).
As per claim 9, it is a method claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above. In addition, Blake further teaches A method for taking a snapshot of a virtual memory of a virtual machine (Blake, Fig. 1, 129 live snapshot area; [0011] lines 1-21, Aspects of the present disclosure address these shortcomings by providing techniques for creating a consistent and reliable snapshot without any VM downtime. A hypervisor creates an overlay disk file to copy data from an original disk file at a reference point in time. The overlay disk file is another disk file that contains the state of the original disk file at the reference point in time…In addition, the hypervisor can create a memory snapshot at the reference point-in-time. The copy of the memory can be generated by copying a process that is executing the VM, which also includes the memory of the VM…The live snapshot is now complete and includes the overlay disk file and the memory snapshot).
As per claims 10 and 13, they are method claims of claims 2 and 5 respectively above. Therefore, they are rejected for the same reasons as claims 2 and 5 respectively above.
As per claim 15, Blake, Wang, Hutcheson and Bushman teach the invention according to claim 9 above. Hutcheson further teaches in response to determining that at least one portion of the virtual memory is annotated, copying the at least one portion of the virtual memory into the persistent memory in a subsequent pass (Hutcheson, Fig. 8B, Data blocks change while copying, 3, 4 change frequently, hold off copying until later pass (as subsequent pass); 840, copied to backup, (only 3, 4 blocks are not copied (annotated to not copy due to change frequently, and hold off until later pass), 850, first pass, copied to backup, changed blocks for use in next pass, 860 second pass, and 870 final pass, copied to backup), and
in response to determining that no portion of the virtual memory is annotated, ceasing copying of the virtual memory into the persistent memory (Hutcheson, Fig. 10A, 1001 changed blocks for use in next copy, 1010 changed blocks in next pass in the first pass, 1020 changed blocks, 3, 4, 20 for copy, 1030 final pass, copied to backup, [Examiner noted: 3, 4, and 20 are the final step copied to backup, and there is no more changed blocks for use in next pass. Therefore, no portion of the virtual memory is annotated (i.e., added to the changed blocks), and copying is stopped/ceasing (i.e., final pass)]; please note virtual memory was taught by Blake).
As per claim 16, it is a system claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above. In addition, Blake further teaches a memory storing a set of instructions; and one or more processors that, when executing the set of instructions, are configured to (Blake, Fig. 4, 400, 402 processor, 404 memory, 426 instructions; Claim 9, A system comprising: a memory; a processing device coupled to the memory, the processing device to).
As per claims 17 and 20, they are system claims of claims 2 and 5 respectively above. Therefore, they are rejected for the same reasons as claims 2 and 5 respectively above.
As per claim 22, it is a system claim of claim 15 above. Therefore, it is rejected for the same reason as claim 15 above.
Claims 3-4, 6, 11-12, 14, 18-19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Blake, Wang, Hutcheson and Bushman, as applied to claims 1, 5, 9, 13, 16 and 20 respectively above, and further in view of SATO (US Pub. 2018/0032272 A1).
SATO was cited in the previous Office Action.
As per claim 3, Blake, Wang, Hutcheson and Bushman teach the invention according to claim 1 above. Hutcheson further teaches wherein the steps further comprise, the first portion is copied into the one or more blocks in the persistent memory in the second pass (Hutcheson, Fig. 4B, 403 target volume (as persistent memory); Fig. 8A, 820, First incremental copy, second pass copy changed blocks; Copied to backup; [0161] lines 10-16, During the first pass of the incremental copy, the changed blocks 3-7, 10, 12-15 are copied, resulting in 10 copy operations. Blocks 1-5, 8, 12, 14, 19-20 changed while copying. As shown at 820, during the second pass of the incremental copy, the changed blocks 1-5, 8, 12, 14, 19-20 are copied, resulting in 10 copy operations).
Although Blake, Wang, Hutcheson and Bushman teach the first portion is copied into the one or more blocks, Blake, Wang, Hutcheson and Bushman fail to specifically teach after the first portion is copied, un-annotating the first portion.
However, SATO teaches after the first portion is copied, un-annotating the first portion (SATO, [0091] lines 1-8, When the copying of the write data of the entry to the non-volatile data memory is completed up to where the mark bit M equals 1 (YES in S42), the second snapshot controller updates the read pointer (in step S45). Further, since the mark bit of the entry is M=1 (in step S42), the second snapshot controller clears the mark bit to M=0 (in step S46). Clearing the mark bit to M=0 means that the copying of the write data has been completed (as after the first portion is copied, un-annotating the first portion; see Fig. 17, the M bit associated with potion of the data (as include first portion)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Blake, Wang, Hutcheson and Bushman with SATO because SATO’s teaching of clearing the mark bit (as un-annotating) once the copying is completed would have provided Blake, Wang, Hutcheson and Bushman’s system with the advantage and capability to allow the system to easily tracking the status of the snapshot process in order to determining whether the copying is finished or not which improving the system performance and efficiency.
As per claim 4, Blake, Wang, Hutcheson and Bushman teach the invention according to claim 1 above. Hutcheson further teaches wherein the steps further comprise copying the first portion in the first pass (Hutcheson, Fig. 8A, 810 first incremental copy, first pass copy changed blocks; copied to backup; [0084] lines 4-5, snapshot the data to create a restore point; Fig. 26, virtual machine 2630; Fig. 8A, 801 3, 4, 5, 6, 10, 12, 13, 15 changed while copying, For use in next copy, 810 first incremental copy, first pass copy changed blocks; [0161] lines 7-12, Blocks 3-6, 10, 12-13, 15 changed while copying. As shown at 810, since the full copy phase completed, blocks 3, 4, 7, 14 changed and are added to the list of blocks to copy. During the first pass of the incremental copy, the changed blocks 3-7, 10, 12-15 are copied).
Blake, Wang, Hutcheson and Bushman fail to specifically teach un-annotating the first portion after copying the first portion.
However, SATO teaches un-annotating the first portion after copying the first portion (SATO, Fig. 10, S46, [0091] lines 1-8, When the copying of the write data of the entry to the non-volatile data memory is completed up to where the mark bit M equals 1 (YES in S42), the second snapshot controller updates the read pointer (in step S45). Further, since the mark bit of the entry is M=1 (in step S42), the second snapshot controller clears the mark bit to M=0 (in step S46). Clearing the mark bit to M=0 means that the copying of the write data has been completed (as after the first portion is copied, un-annotating the first portion; see Fig. 17, the M bit associated with potion of the data (as include first portion); also see [0093] lines 3-13, copying of the write data is not completed, the non-volatile log memory is in a state where the entry with a mark bit of M=1 still remains in an entry after the read pointer...As such, the operation of copying, to the non-volatile data memory, the write data from the read pointer up to the entry with the mark bit of M=1 in the non-volatile log memory is continued).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Blake, Wang, Hutcheson and Bushman with SATO because SATO’s teaching of clearing the mark bit (as un-annotating) once the copying is completed would have provided Blake, Wang, Hutcheson and Bushman’s system with the advantage and capability to allow the system to easily tracking the status of the snapshot process in order to determining whether the copying is finished or not which improving the system performance and efficiency.
As per claim 6, Blake, Wang, Hutcheson and Bushman teach the invention according to claim 5 above. Hutcheson further teaches wherein the steps further comprise, the second portion is copied into the one or more blocks in the persistent memory (Hutcheson, Fig. 8A, 810 First incremental copy, first pass copy changed blocks, changed blocks, 3, 4, 7, 14 changed (as second portion changed after applying the write request) since the first phase, add to changed blocks Blocks_to_copy (i.e., second portion is annotated for copying in the first pass), copying to backup).
Blake, Wang, Hutcheson and Bushman fail to specifically teach after the second portion is copied, un-annotating the second portion.
However, SATO teaches after the second portion is copied, un-annotating the second portion (SATO, Fig. 10, S46; Fig. 17, the M bit associated with potion of the data (as include second portion); [0091] lines 1-8, When the copying of the write data of the entry to the non-volatile data memory is completed up to where the mark bit M equals 1 (YES in S42), the second snapshot controller updates the read pointer (in step S45). Further, since the mark bit of the entry is M=1 (in step S42), the second snapshot controller clears the mark bit to M=0 (in step S46). Clearing the mark bit to M=0 means that the copying of the write data has been completed (as after the first portion is copied, un-annotating the first portion; also see [0093] lines 3-13, copying of the write data is not completed, the non-volatile log memory is in a state where the entry with a mark bit of M=1 still remains in an entry after the read pointer...As such, the operation of copying, to the non-volatile data memory, the write data from the read pointer up to the entry with the mark bit of M=1 in the non-volatile log memory is continued).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Blake, Wang, Hutcheson and Bushman with SATO because SATO’s teaching of clearing the mark bit (as un-annotating) once the copying is completed would have provided Blake, Wang, Hutcheson and Bushman’s system with the advantage and capability to allow the system to easily tracking the status of the snapshot process in order to determining whether the copying is finished or not which improving the system performance and efficiency.
As per claims 11-12 and 14, they are method claims of claims 3-4 and 6 respectively above. Therefore, they are rejected for the same reasons as claims 3-4 and 6 respectively above.
As per claims 18-19 and 21, they are system claims of claims 3-4 and 6 respectively above. Therefore, they are rejected for the same reasons as claims 3-4 and 6 respectively above.
Response to Arguments
In the remark Applicant’s argue in substance:
(a), Claim 1 recites the limitations of "copying the first portion into the one or more blocks in the persistent memory in the first pass without pausing a virtual machine to which the virtual memory is allocated." None of the references cited by the Examiner teaches or suggests these limitations…Applicant submits that Blake, Wang, Hutcheson, and Bushman fail to render claim 1 obvious. In the rejection set forth by the Office Action the Examiner maps "copying the first portion into the one or more blocks in the persistent memory in the first pass without pausing a virtual machine to which the virtual memory is allocated," recited in claim 1, to the idea in Blake of performing a memory dump to transfer the memory of a child process to a live snapshot to capture the child process memory. See Office Action at pages 9-10. Based on this mapping advanced by the Examiner, Blake would have to disclose that the child process is not paused. However, Blake explicitly discloses that the child process is frozen during the memory dump so that there is no read or write activity performed to the child memory. See Blake at paragraph [0031] and Figure 3, step 304. Importantly, Blake teaches away from claim 1 in this regard. In view of these distinctions, Blake cannot be properly interpreted as teaching or suggesting the above limitations of claim 1.
Examiner respectfully disagreed with Applicant’s argument for the following reasons:
As to point (a), in response to applicant’s argument that “copying the first portion into the one or more blocks in the persistent memory in the first pass without pausing a virtual machine to which the virtual memory is allocated." None of the references cited by the Examiner teaches or suggests these limitations…Applicant submits that Blake, Wang, Hutcheson, and Bushman fail to render claim 1 obvious. In the rejection set forth by the Office Action the Examiner maps "copying the first portion into the one or more blocks in the persistent memory in the first pass without pausing a virtual machine to which the virtual memory is allocated," recited in claim 1, to the idea in Blake of performing a memory dump to transfer the memory of a child process to a live snapshot to capture the child process memory”. Examiner respectfully disagreed.
Firstly, applicant mischaracterizing examiner’s mapping by indicating that “copying the first portion into the one or more blocks in the persistent memory in the first pass without pausing a virtual machine to which the virtual memory is allocated recited in claim 1, to the idea in Blake of performing a memory dump to transfer the memory of a child process to a live snapshot to capture the child process memory”.
In fact, examiner does not mapping the “child process” to the virtual machine, Examiner is mapping the virtual machine of Blake to the claimed limitation of “virtual machine”. Blake teaches live snapshot of the virtual machine with snapshot of the virtual memory without virtual machine downtime.
Secondly, applicant’s mischaracterizing the whole teaching of Blake reference and arguing that Blake teaches away from claim 1. Examiner directs applicant to review the whole disclosure of Blake reference. That is, Blake clearly teaches copying the first portion into the one or more areas in the persistent memory in the first pass without pausing a virtual machine to which the virtual memory is allocated. For example, Blake teaches a virtual machine live snapshot system that take the snapshots at various points in time, it creating a consistent and reliable snapshot without any VM downtime.
For explanation purpose regarding applicant’s argument about “child process”. Blake, at paragraph [0030], it recites Referring to FIG. 3, in one implementation, method 300 begins at block 302, with the hypervisor issuing a fork system call to replicate a parent process associated with the VM memory at a reference point in time. The hypervisor can issue the fork system call in response to receiving a request to take a snapshot. As a result of the fork system call, the memory of the VM (the original or "parent" process running the VM) can be marked as shared, and a new (child) process can be created with the same view of the shared memory and paragraph [0031] it recites At block 304, the hypervisor freezes the child process associated with child memory that corresponds to the shared memory to preserve the state of the memory at the reference point in time. When the child process is frozen, there is no activity (e.g., read/write operations) to the child memory. As to the parent process, if the parent process attempts to write into a page of memory that is still shared by the parent and child, then the memory is changed to no longer be shared, causing the parent process to write to its own memory for that page of memory. At block 306, the child memory is dumped to a destination storage to form a memory snapshot. The memory snapshot can be used to create a live snapshot at the reference point in time.
That is, the “child process” is one of a process that used for performing the live snapshot of the virtual memory/VM. It does NOT pausing the virtual machine itself. This technique is related to a copy-on-write (COW) live snapshot (see [0020] The snapshot manager 108 can invoke copy on write).
Here is the flow: The hypervisor issues fork(): Parent process = currently running VM; Child process = snapshot view of the VM at that instant; and Memory pages are marked as shared. Both parent and child initially reference the same physical memory pages. The child process is frozen, and its memory becomes a preserved point-in-time image. So, no further modifications occur in the child.
The parent VM continues running if the VM writes to a shared page: copy-on-write occurs a private copy is created for the parent. Child retains the original page contents. The child memory is dumped to storage. Because child memory is frozen, it represents a consistent snapshot.
That means, the parent VM is still active and executing (see [0031] “As to the parent process, if the parent process attempts to write into a page of memory that is still shared by the parent and child, then the memory is changed to no longer be shared, causing the parent process to write to its own memory for that page of memory”). Therefore, the child process is paused/frozen, not the active VM itself.
Further, Wang teaches when copying into the one or more areas, it is copying into the one or more blocks (Wang, Fig. 1, 109 file system, 113, 115, 117, 119 (as snapshots); Col 4, lines 34-36, storage 101 may store one or more datasets 103 for file system 109 in one or more blocks as basic storage allocation units; Col 4, lines 42-43, clones 113, 115, 117 and live 119, to represent corresponding datasets 103; Col 14, lines 12-14, Claim 7, maintain a plurality of snapshots of data stored in one or more extents of consecutive blocks allocated in a storage (as allocating one or more blocks which is for storing/copying snapshot)). Please refers to 103 rejection above.
For the reasons above, Applicant’s argument has not been found to be persuasive, and therefore the rejections are maintained.
Conclusion
THIS ACTION IS MADE FINAL. 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 ZUJIA XU whose telephone number is (571)272-0954. The examiner can normally be reached M-F 9:30-5:30 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, Aimee J Li can be reached at (571) 272-4169. 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.
/ZUJIA XU/Examiner, Art Unit 2195
Prosecution Insights