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 Request for Continued Examination and Applicant Amendment and Arguments filed on 17 July, 2026.
Claims 1-22 are pending for examination.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 17 July, 2026 has been entered.
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), Bushman (US Patent. 9,727,264 B1) and Venketaraman et al. (US Pub. 2020/0050681 A1).
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.
Blake, Wang, Hutcheson and Bushman fail to specifically teach copying the snapshot from the persistent memory to storage upon completion; and deallocating the one or more blocks associated with the virtual memory from the persistent memory.
However, Venketaraman teaches copying the snapshot from the persistent memory to storage upon completion (Venketaraman, Fig. 1B, 142 persistent memory, 110 storage device, 148 and 154 snapshot of FS1 data units; Fig. 1C, B164, B166; [0046] In block B162, a snapshot (referred to as L2 snap-1 (FIGS. 1D-1E) is taken by FS1 144. In one aspect, before taking the snapshot, any I/O request by one or more applications is fenced (i.e. held) to complete the snapshot operation by FS1 144. The amount of time it takes to write data to the LUNs at storage devices 110 is proportional to the amount of data units at PM 142. By taking an instantaneous snapshot in the PM-based filesystem, I/Os can be unfenced quickly; [0047] After the snapshot is taken, in block B164, the metadata for the data units in L2 snapshot is encoded and written to storage devices 110. The metadata includes timestamps, access rights, a unique identifier for the snapshot, storage location of the snapshot, size of the snapshot, number of data units or any other information (pointers, links and others) that may be needed to restore data units and metadata associated with the data units from the snapshot; [0048] a snapshot of the LUNs at storage device 110 is taken. This snapshot is referred to as L3 snap-1 (FIGS. 1D-1E). In one aspect, the LUN based snapshot is taken after the data units and the metadata blocks of the PM-filesystem snapshot (L2 snap-1) have been flushed to the LUNs of storage devices 110. The L3 snapshot is uniquely identified and indicates that the FS1 144 snapshot is included in it.); and
deallocating the one or more blocks associated with the virtual memory from the persistent memory (Venketaraman, [0049] In block B168, the FS1 144 based snapshot or its data units may be optionally deleted. This reclaims storage space at PM 142; Claim 1, deleting the first snapshot at the computing device, after the second snapshot is generated and releasing storage blocks from the persistent memory associated with the first snapshot; please note: one or more blocks associated with the virtual memory was taught by Blake, Wang and Hutcheson).
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 Venketaraman because Venketaraman’s teaching of releasing storage blocks from the persistent memory associated with the first snapshot would have provided Blake, Wang, Hutcheson and Bushman’s system with the advantage and capability to allow the system to free the storage space of the persistent memory which improving the resource utilization and system efficiency.
As per claim 2, Blake, Wang, Hutcheson, Bushman and Venketaraman 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, Bushman and Venketaraman 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, Bushman and Venketaraman 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, Bushman and Venketaraman 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, Bushman and Venketaraman 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, Bushman and Venketaraman, 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, Bushman and Venketaraman 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, Bushman and Venketaraman teach the first portion is copied into the one or more blocks, Blake, Wang, Hutcheson, Bushman and Venketaraman 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, Bushman and Venketaraman 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, Bushman and Venketaraman’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, Bushman and Venketaraman 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, Bushman and Venketaraman 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, Bushman and Venketaraman 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, Bushman and Venketaraman’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, Bushman and Venketaraman 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, Bushman and Venketaraman 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, Bushman and Venketaraman 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, Bushman and Venketaraman’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
Applicant’s arguments with respect to claims 1-22 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
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/Primary Examiner, Art Unit 2195
Prosecution Insights