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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-9, 11-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over HSU et al. (US 20140095817) in view of Venkataramana et al. (US 20210124495).
As per claim 1, HSU teaches the invention substantially as claimed including a method for managing virtual machines (VMs), comprising:
obtaining... a backup request for a full backup of a VM ([0039], The process is initiated with a request to back up a VM. The request may come from a client based on a backup schedule, or it may come from a user directly through a user interface. At task box 1, backup engine 106 sends out a request to backup with a VM identifier (indicating VM 113 in this example) to VMM 112, which hosts the to-be-backed-up VM 113);
in response to the backup request:
performing a logical slicing of VM data associated with the virtual machine ([0039], VMM 112 establishes the consistent state of VM 113 by taking a VM snapshot. The VM snapshot triggers the creation of one or more snapshots of the content files associated with the VM (e.g. VM disk images) in and/or by storage system 180. Such snapshots are referred to as disk snapshots in this specification. In task box 3, via API 132, backup engine 106 remotely identifies the consistent state of VM 113, which includes a list of the disk snapshots created in storage system 180 in one embodiment; and [0040], storage system 180 divides the disk snapshots into segments) based on a slicing policy to obtain a set of logical slices ([0030], In response to a data file to be stored in storage units 108-109, optional deduplication storage engine 107 is configured to segment the data file into multiple segments according to a variety of segmentation policies or rules);
initiating generation of a backup of each logical slice in the set of logical slices to obtain a set of backup slices ([0039], Backup engine 106 then requests storage system 180 to send VM disk images associated with the consistent state of the VM to a target backup storage at task box 4. In one embodiment, the VM disk images are disk snapshots resulting from VM snapshot initiated by VMM 112);
storing the set of backup slices in a backup storage system ([0039], backup logic 184 then identifies the requested VM disk images. In this example, they are represented by VM disk file 186. VM disk file 186 may take a format of a virtual machine disk (VMDK) provided by VMware. Backup logic 184 copies VM disk file 186 associated with VM 113 to backup storage system 104... the disk snapshots for VM 113 are parsed and metadata in the disk snapshots are interpreted to determine information about the files contained in the disk snapshots. Such information includes file attributes such as file name, access control information, and information about layout of the files within the disk snapshot. The information is then used to populate a backup catalog 111 of the files in the VM that was backed up. The disk snapshots are then saved as VM backup files 142 in storage unit 108... the backup content may be further deduplicated into deduplicated segments and the deduplicated segments are then stored in one or more physical disks of the backup storage system);
after storing the set of backup slices, obtaining a second backup request for a virtual synthetic backup of the VM ([0039], The process is initiated with a request to back up a VM. The request may come from a client based on a backup schedule, or it may come from a user directly through a user interface. At task box 1, backup engine 106 sends out a request to backup with a VM identifier (indicating VM 113 in this example) to VMM 112, which hosts the to-be-backed-up VM 113);
in response to the second backup request:
obtaining a tracked changes file associated with the VM data after the full backup ([0047], a storage system performs a comparison such as a "diff" operation of the identified VM disk images against the corresponding VM disk images associated with a previous snapshot of the VM to determine the changes since the last backup (e.g., the delta between the VM disk image and the last backup). In one embodiment, the VM disk image is a disk snapshot. In another embodiment, the storage system tracks the changes to a disk since the last disk snapshot was taken and determines the changes since the last backup by using this tracking information);
performing a slicing analysis of tracked changes in the tracked changes file to identify a backup slice associated with each of the tracked changes ([0047], a storage system performs a comparison such as a "diff" operation of the identified VM disk images against the corresponding VM disk images associated with a previous snapshot of the VM to determine the changes since the last backup (e.g., the delta between the VM disk image and the last backup). In one embodiment, the VM disk image is a disk snapshot. In another embodiment, the storage system tracks the changes to a disk since the last disk snapshot was taken and determines the changes since the last backup by using this tracking information); and
based on the slicing analysis, initiating storage of the virtual synthetic backup using the tracked changes file and the set of backup slices ([0048], The changes since the last backup are copied to the backup storage system for backup. In one embodiment, the backup storage system creates a copy of the previous full backup in the backup storage system and applies the copied changes to the copy of the previous full backup to obtain a synthetic full backup. In another embodiment, the storage system sends the changes since last backup together with recipes to the backup storage system to enable the backup storage system to create a synthetic full backup based on contents of the previous full backup).
HSU fails to specifically teach, obtaining, by a backup agent, a backup request for a full backup of a VM.
However, Venkataramana teaches, obtaining, by a backup agent, a backup request for a full backup of a VM ([0040], client(s) (100) may trigger a backup operation performed by the backup server (120A) by sending a backup request to the backup agent (116A) that specifies backing up the virtual machine (112)).
HSU and Venkataramana are analogous because they are each related managing virtual machines. HSU teaches a method of incremental virtual machine backups using segmented snapshots to backup changed segments of virtual machine data. (Abstract, a request for an incremental backing up a virtual machine (VM) is received at a storage system, the request identifying a requested VM disk image associated with a consistent state of the VM. The storage system determines a difference between the requested VM disk image and a previous VM disk image representing a previous VM backup. The changes between the requested VM disk image and a previous VM disk image are then transmitted to a target backup storage system). Venkataramana teaches a backup agent that performs virtual machine backups. (Abstract, method for performing a backup operation includes obtaining, by a backup server, a backup request, wherein the backup request specifies a virtual machine to be backed up, wherein the virtual machine is hosted by a production host; and [0023], backup agent may include functionality for generating backups of the virtual machine (112) and/or sending the backups to the backup server (120A) for further processing. The backup agent may perform the backup generation ). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the backup system of HSU would be modified with the backup agent taught by Venkataramana resulting in a system that manages virtual machine backups utilizing a backup agent that is able to manage backup operations. Therefore, it would have been obvious to combine the teachings of HSU and Venkataramana.
As per claim 3, HSU teaches, wherein the slicing analysis comprises:
selecting a first tracked change of the tracked changes ([0050], disk change tracker 788 tracks the changes to a disk since the last disk snapshot was taken and determines the changes since the last backup by using this tracking information. At task box 6, the identified changes of VM disk images are backed up to backup storage system 104; and [0052], the changes of disk snapshots are tracked by either disk change tracker 788 or backup logic 184. The changes of VM disk images are then backed up to a target backup storage system at block 908); and
making a determination that the first tracked change is associated with a first backup slice of the set of backup slices ([0052], the changes of disk snapshots are tracked by either disk change tracker 788 or backup logic 184. The changes of VM disk images are then backed up to a target backup storage system at block 908).
As per claim 4, HSU teaches, wherein initiating storage of the virtual synthetic backup comprises:
generating a new backup slice for the first tracked change ([0030], deduplication storage engine 107 is configured to segment the data file into multiple segments according to a variety of segmentation policies or rules);
storing a VM backup metadata file associated with the new backup slice ([0030], Deduplication storage engine 107 only stores a segment in a storage unit if the segment has not been previously stored in the storage unit); and
storing, in the VM backup metadata file, a fast copy of the first backup slice ([0055], In the event that a segment has already been stored in storage unit(s), a reference to the previously stored segment is stored, for example, in a segment tree associated with the file, instead of storing the newly received segment).
As per claim 5, HSU teaches, wherein the fast copy is a pointer to the first backup slice ([0055], In the event that a segment has already been stored in storage unit(s), a reference to the previously stored segment is stored, for example, in a segment tree associated with the file, instead of storing the newly received segment).
As per claim 6, HSU teaches, wherein a backup slice of the set of backup slices comprises a portion of the VM data associated with one of the set of logical slices ([0023], the copied disk snapshots are parsed in the target backup storage system. Metadata in the disk snapshots are interpreted to determine information about the files contained in the disk snapshots; and [0040], system 180 divides the disk snapshots into segments) and a VM backup metadata file ([0023], Metadata in the disk snapshots are interpreted to determine information about the files contained in the disk snapshots. Such information includes file attributes such as file name, access control information, and information about layout of the file within the disk snapshots. Such information is then used to populate a backup catalog of the files in the backed up VM. The copied disk snapshots may further be deduplicated and stored in the backup storage system as deduplicated segment).
As per claim 7, HSU teaches, wherein the VM backup metadata file comprises a set of attributes associated with the portion of the VM data ([0023], Metadata in the disk snapshots are interpreted to determine information about the files contained in the disk snapshots. Such information includes file attributes such as file name, access control information, and information about layout of the file within the disk snapshots. Such information is then used to populate a backup catalog of the files in the backed up VM).
As per claim 8, HSU teaches, wherein one of the set of attributes is a storage location of a file of the VM data ([0032], metadata information includes a file name, a storage unit where the segments associated with the file name are stored, reconstruction information for the file using the segments, and any other appropriate metadata information... Metadata information further includes index information (e.g., location information for segments in storage units)).
As per claim 9, this is the “non-transitory computer readable medium claim” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 11, this claim is similar to claim 3 and is rejected for the same reasons.
As per claim 12, this claim is similar to claim 4 and is rejected for the same reasons.
As per claim 13, this claim is similar to claim 5 and is rejected for the same reasons.
As per claim 14, this claim is similar to claim 6 and is rejected for the same reasons.
As per claim 15, this claim is similar to claim 7 and is rejected for the same reasons.
As per claim 16, this claim is similar to claim 8 and is rejected for the same reasons.
As per claim 17, this is the “system claim” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 19, this claim is similar to claim 3 and is rejected for the same reasons.
As per claim 20, this claim is similar to claim 4 and is rejected for the same reasons.
Claims 2, 10, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of HSU-Venkataramana as applied to independent claims 1, 9, and 17 and in further view of Naik et al. (US 9311375).
As per claim 2, the combination of HSU- Venkataramana fails to specifically teach, wherein the VM data is a size larger than 200 gigabytes (GB).
However, Naik teaches, wherein the VM data is a size larger than 200 gigabytes (GB) (Column 3, Lines 28-30, Virtual machine files can be large and it is not uncommon for a virtual machine file to exceed 10s or 100s of gigabytes (GB) in size).
The combination of HSU-Venkataramana and Naik are analogous because they are each related managing virtual machines. HSU teaches a method of incremental virtual machine backups using segmented snapshots to backup changed segments of virtual machine data. Venkataramana teaches a backup agent that performs virtual machine backups. Naik teaches a method of compacting large virtual machines prior to copying in order to reduce the size of virtual machine backups. (Column 2, Lines 21-29, the system determines the size of the source virtual machine file prior to creating the destination virtual machine file. In response to determining that the size of the source virtual machine file satisfies a threshold, the system may create the destination virtual machine file. In some embodiments, determining that the size of the source virtual machine file satisfies the threshold further comprises the system determining whether the size of the source virtual machine exceeds a threshold size; Column 7, Lines 61-63, compactor 122 may use the duplicator 124 to duplicate part or all of a virtual machine file 116 as part of the compaction process; and Column 12, Lines 55-57, some or all of the process 400 can be performed as part of a backup process to reduce the size of backups of virtual machine files). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the backup system of the combination of HSU-Venkataramana would be modified with the compaction process taught by Naik resulting in a system that reduces the size of virtual machine backups. Therefore, it would have been obvious to combine the teachings of the combination of HSU-Venkataramana and Naik.
As per claim 10, this claim is similar to claim 2 and is rejected for the same reasons. The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 18, this claim is similar to claim 2 and is rejected for the same reasons. The same motivation used in the rejection of claim 2 is applicable to the instant claim.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is as follows:
Zhang et al. (20210349651)- Teaches incremental backup operations including dividing backups into backup extents:
[0023], a backup copy of data object 132 may be backed up to second backup system 120 according to a backup request;
[0025], Backup copy 210 is divided into multiple backup extents 212, . . . , and 214. At this moment, second backup system 120 is no longer empty in the initial phase; instead, it already includes backup extents 212, . . . , and 214. When a backup request for backing up data object 132 in application system 130 is received, data object 132 may be compared with multiple backup extents 212, . . . , and 214 to determine which data in data object 132 needs to be transmitted to second backup system 120; and
[0083], Backup copy 210 may be divided into multiple backup extents 212, . . . , and 214. The backup extents obtained by the division may be stored to extent storage 510; and
Botelho (20220374519)- Teaches decomposing snapshots:
[0285], snapshots are decomposed into images, which are stored in the data store 5518... the snapshot of machine x taken at time y can be constructed from the images a,b,c. The image table 5628 is an index of images to their location in the data store 5518.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MELISSA A HEADLY whose telephone number is (571)272-1972. The examiner can normally be reached Monday- Friday 9-5:30pm.
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, Bradley Teets can be reached at 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/MELISSA A. HEADLY/
Examiner Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights