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 .
Claims 1-20 are presented for examination.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2, 10, and 18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As to claim 2, the limitation of “restoring, after the initiating, the incremental backup in the backup storage system” is indefinite because it is unclear as to what object is being restored. The specification consistently describes restoring a VM using backup data from the backup storage system ([0023], [0027], [0077]-[0080], and [0083]), not restoring the incremental backup itself, as claimed. These interpretations are inconsistent with the specification and render the scope unclear. Therefore, claim 2 is indefinite.
Claims 10 and 18 are also rejected for the same reasons as stated in the rejection of claim 2.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Derk et al. (hereinafter DERK) (US 2019/0384680 A1) in view of HECKEL (US 2021/0318934 A1).
As to claim 1, DERK teaches a method for managing virtual machines (VMs) (VMs 106a and/or VMs 106b) ([0015]; Fig. 1), comprising:
obtaining, by a backup agent (Backup Manager 120 or backup program such as IBM® Tivoli® Storage Manager), a backup request for an incremental backup of a VM (in response to a user creating an incremental backup, such as a snapshot operation; backups are incremental backups of only changed data) ([0002]; [0017]-[0019]; Fig. 1);
in response to the backup request: obtaining a resilient change tracking (RCT) data structure (via changed block tracking (“CBT”) mechanism) associated with the VM (utilizing change block tracking (CBT) technology that provides only data that has changed between backups to create backup versions) ([0004]; [0016]-[0017]);
a set of tracked changes specified in the RCT based on offset (block allocation table (“BAT”) 302 specifies offset for each block) ([0022]; Fig. 3);
performing a size normalization (normalize to a common data format) of the set of tracked changes to obtain a set of normalized blocks ([0002]);
storing a normalized blocks metadata table in the backup agent, wherein the normalized blocks metadata table comprises a mapping between the set of tracked changes and the set of normalized blocks (normalized to a command data format; mapping variable length format to a fixed block length consistent with a common data format used by the backup manager 120, etc.) ([0002]; [0024]; [0027]); and
initiating storage of the incremental backup in a backup storage system (Backup Storage 122) using the normalized blocks metadata table (Fig. 1).
DERK teaches a set of tracked changes specified in the RCT based on offset (block allocation table (“BAT”) 302 specifies offset for each block) ([0022]; Fig. 3), but does not explicitly teach sorting it. However, HECKEL teaches sorting data associated with backup operations based on offset ([0034]; [0254]-[0255]; [0183]-[0184]; [0052]; Figs 1-3). It would have been obvious to one of ordinary skill in the art before the effective date of the application to sort the data of DERK’s set of tracked changes specified in the RCT based on offset, as taught and suggested in HECKEL. The suggestion/motivation for doing so would have been to provide the predicted result of providing significant performance improvement and optimization of the sequential reads processing due to sorting (HECKEL: [0034]).
As to claim 2, DERK teaches the method of claim 1, further comprising: restoring, after the initiating, the incremental backup (incremental forever backup, incremental backups, etc.) in the backup storage system (Backup Storage System 660) (Abstract; [0004]-[0005]; [0028]-[0030]; Fig. 6B).
As to claim 3, DERK teaches the method of claim 1, wherein the size normalization (normalize the storage of data to a common data format) comprises converting each tracked change in the set of tracked changes to a size that is divisible by a pre-determined size (fixed block length, such as 16 KB) ([0002]-[0004]; [0018]; [0024]).
As to claim 4, DERK does not explicitly teach the method of claim 3, wherein the pre-determined size is 8 kilobytes (KB). DERK’s teachings of a “number n fixed block length” shows that the size can be pre-determined or pre-selected, and gives one possible example of “16 KB” ([0024]). It would have been obvious to one of ordinary skill in the art before the effective date of the application to select other known or standard block sizes, such as 8 KB, based on system requirements of storage efficiency or compatibility.
As to claim 5, DERK teaches the method of claim 1, wherein the incremental backup comprises changes to VM data of the VM and a VM backup metadata file (CBT provides incremental backups or only data that has changed between backups), and wherein the VM data is specified in the set of normalized blocks (normalized data format, known as the common data format, which stores data in a fixed block length blocks, such as 16 KB) ([0004]; [0018]; [0021]-[0023]; Figs 2 and 3).
As to claim 6, DERK teaches the method of claim 5, wherein the VM backup metadata file comprises a set of attributes (metadata such as file system structures, e.g., directories and files, a layout of the blocks on the virtual disk, point-in-time information of the data) associated with the VM data ([0021]; Fig. 2).
As to claim 7, DERK teaches the method of claim 6, wherein one of the set of attributes is a storage location of a file of the VM data (block allocation table (“BAT”) 302 that specifies the state and physical file offset for each block, wherein physical offsets are the storage locations of VM data blocks/files) ([0022]; Figs. 2 and 3).
As to claim 8, DERK teaches the method of claim 1, wherein the RCT (CBT) data structure is generated in a production host environment based on changes made to a the VM during a period of time after the generation of a previous backup (hypervisor 104a that uses change block tracking (CBT)) ([0004]; [0016]; [0019]; Fig. 1).
As to claim 9, it is rejected for the same reasons as stated in the rejection of claim 1.
As to claim 10, it is rejected for the same reasons as stated in the rejection of claim 2.
As to claim 11, it is rejected for the same reasons as stated in the rejection of claim 3.
As to claim 12, it is rejected for the same reasons as stated in the rejection of claim 4.
As to claim 13, it is rejected for the same reasons as stated in the rejection of claim 5.
As to claim 14, it is rejected for the same reasons as stated in the rejection of claim 6.
As to claim 15, it is rejected for the same reasons as stated in the rejection of claim 7.
As to claim 16, it is rejected for the same reasons as stated in the rejection of claim 8.
As to claim 17, it is rejected for the same reasons as stated in the rejection of claim 1.
As to claim 18, it is rejected for the same reasons as stated in the rejection of claim 2.
As to claim 19, it is rejected for the same reasons as stated in the rejection of claim 3.
As to claim 20, it is rejected for the same reasons as stated in the rejection of claim 4.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH TANG whose telephone number is (571)272-3772. The examiner can normally be reached Monday-Friday 7AM-3PM.
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.
/KENNETH TANG/Primary Examiner, Art Unit 2197
Prosecution Insights