DETAILED ACTION
This communication is responsive to the application, filed March 27, 2024. Claims 1-17 and 19-21 are pending in this application. The applicant has canceled claim 18. The applicant has added new claim 21.
Examined under the first inventor to file provisions of the AIA
The present application was filed on March 27, 2024, which is on or after March 16, 2013, and thus is being examined under the first inventor to file provisions of the AIA .
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 of this title, 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-5, 8, 10-12, and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Dornemann et al. (US 9,823,977 B2) in view of Muth et al. (US 7,415,488 B1).
As per claim 1: A data storage method of a virtual machine, comprising:
acquiring a starting instruction of a virtual machine, and loading a storage device according to the starting instruction;
Dornemann discloses [col. 3, lines 11-61] the VM is executed by the hypervisor. The hypervisor provides a virtual disk and each VM has one or more virtual disks. The VM sends a command to open the virtual hard disk file and begin monitoring the virtual hard disk in response to intercepting the open operation. This indicates that the VM startup/open is the “starting instruction” and the virtual hard disk (storage device) is loaded/opened per that instruction.
accessing metadata information recorded in first storage regions of at least two corresponding files in the storage device, and verifying the metadata information to obtain a verification result;
Dornemann discloses [Figs. 3-6; col. 49-51] the VM comprises a virtual disk file and a change block bitmap file (two corresponding files exist, VHD and bitmap). The driver determines an identity of the first sector, determines an entry in the change block bitmap file, and validate a change block bitmap file. The timestamp is compared in the header of the change block bitmap file with a timestamp of the virtual hard disk file. If the timestamp is older, the respective hypervisor can invalidate all changes to the bitmap file and start over. This indicates both have structured headers/metadata, verification includes header/timestamp checks and validating the bitmap against the disk state to obtain a pass/fail result.
determining, according to the data region bitmap information, data storage states of the at least two corresponding files; and
Dornemann discloses [Fig. 4; col. 49, lines 4-29] the change block bitmap file may include various entries. The bit entry of a plurality of bit entries may be associated with a virtual hard disk file. The bit entries indicate whether any sector in the corresponding extent has changed or has not been changed. These states are used as the per-file data storage states.
in response to the data storage states of the at least two corresponding files being both normal, sending target data to the at least two corresponding files to perform data storage.
Dornemann discloses [Fig. 5; col. 49, lines 30-67] receiving a write operation and modifying change block bitmap indicating the first sector is modified. For each extent that has changed, the entries in the bitmap file are modified and the write operation is performed. This indicates that when states are appropriate, the write operations proceed. The data goes to the virtual hard disk (target data) and the bitmap file is updated (the second corresponding file).
in response to the verification result being normal, accessing data region bitmap information recorded in second storage regions of the at least two corresponding files;
Dornemann discloses [Fig. 6; col. 50-51] validating a change block bitmap file and identifying one or more extents based on the retrieved change block bitmap file. The change block bitmap file is stored in the VM volume. Dornemann discloses bitmap tracking and recording bitmap information, but fails to explicitly disclose recording bitmap information in designated storage regions of multiple corresponding files. Muth discloses a similar method, which further teaches [Fig. 2A; col. 7, lines 31-65] file system configured to store dirty file information in a file system log. The redundancy abstract manager may be configured to implement dirty region tracking for redundancy consistency recovery. This teaches the bitmap information (dirty region tracking) used to determine data storage states across multiple corresponding files/mirrors (in the context of RAID and mirrored volumes).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the change tracking technique of Dornemann with that of Muth. One would have been motivated to access second storage region because it allows to perform consistency recovery on any aggregated storage system that provides redundant storage [Muth; col. 4, lines 20-30].
As per claim 2: The method according to claim 1, wherein the method further comprises:
accessing first identifier information of third storage regions of the at least two corresponding files;
Dornemann discloses [Figs. 3-6; col. 49-51] the VM comprises a virtual disk file and a change block bitmap file (two corresponding files exist, VHD and bitmap). The driver determines an identity of the first sector, determines an entry in the change block bitmap file, and validate a change block bitmap file. The timestamp is compared in the header of the change block bitmap file with a timestamp of the virtual hard disk file. The “first identifier information” in “third storage regions” maps to per-file header identifiers (e.g. timestamps/metadata read from the VHD file and the bitmap file).
and in response to the first identifier information being consistent, determining that data stored in the at least two corresponding files is consistent, and
Dornemann discloses [Fig. 6; col. 50-51] validating a change block bitmap file and identifying one or more extents based on the retrieved change block bitmap file. The change block bitmap file is stored in the VM volume. This indicates that upon normal validation, the system accesses the change block bitmap (separate file/region) as the “second storage region” to drive subsequent operations.
in response to the first identifier information being inconsistent, determining that the data stored in the at least two corresponding files is inconsistent, and performing data synchronization on the data stored in the at least two corresponding files.
Dornemann discloses [col. 50, lines 34-49] if the timestamp of the bitmap file is older, the driver may discard and the VM data agent may revert to performing full backup, disable change tracking, and re-enable after full backup, creating a new change block bitmap file. The identifier mismatch implies inconsistencies and the system triggers a synchronization (full backup) to restore consistency between the files.
As per claim 3: The method according to claim 1, wherein the method further comprises:
in response to the virtual machine being run abnormally, controlling data in the second storage regions of the at least two corresponding files to be consistent
Muth discloses [Fig. 8; col. 14-15] after a system crash or other errors (abnormal error/crash), performing mirror synchronization by synchronize/replaying the file system log, identifying portions to be synchronized, and copying the identified portions from one mirror volume to the other mirrors. This indicates on an abnormal run/crash, the system forces consistency of tracked change regions (second storage regions) of the bitmap/logged dirty regions across copies/files.
and controlling data in third storage regions of the at least two corresponding files to be consistent; and
Muth discloses [Fig. 9; col. 16-17] synchronizing the file system log across the mirrors, traversing the logs, and copying only the identified log entries. The “third storage regions” map to log/metadata header regions that are also reconciled to a consistent state after crash/error.
in response to one of the at least two corresponding files being abnormal, recording information of an abnormal file of the at least two corresponding files in a first storage region of a normal file of the at least two corresponding files.
Muth discloses [Fig. 7; col. 12-13] saving dirty file information that indicates portions of the file to be modified in a file system log, update and synchronize file information, and use saved dirty file information to determine files to be synchronized. This indicates the normal files metadata/log (a first storage region) records which counterpart/files is out-of-sync or dirty so recovery can target it.
As per claim 4: The method according to claim 1, wherein the accessing metadata information recorded in first storage regions of at least two corresponding files in the storage device, and verifying the metadata information to obtain a verification result comprises:
comparing the metadata information recorded in the first storage regions of the at least two corresponding files; and
in response to the metadata information being consistent, determining that the verification result is normal, and in response to the metadata information being inconsistent, determining that the verification result is abnormal.
Muth discloses [Figs. 7-9; col 14-16] performing file/volume consistency checks by maintaining and comparing status/metadata across mirrored copies, including dirty file log info and dirty region maps. This inherently yields a comparison result over two corresponding copies (consistent is normal; inconsistent is abnormal). The mirror/replica systems use the comparison outcome to flag “in sync/out of sync”.
As per claim 5: The method according to claim 4, wherein the determining, according to the data region bitmap information, data storage states of the at least two corresponding files comprises:
generating at least two pieces of corresponding second identifier information according to the data region bitmap information recorded in the second storage regions of the at least two corresponding files;
comparing the at least two pieces of corresponding second identifier information; and
in response to the at least two pieces of corresponding second identifier information being consistent, determining that the data storage states of the at least two corresponding files are normal, and in response to the at least two pieces of corresponding second identifier information being inconsistent, determining that the data storage states of the at least two corresponding files are abnormal.
Dornemann discloses [col. 49, lines 4-29] the virtual hard disk and the change block bitmap. The change block bitmap file may include various bit entries. The values in the bit entries indicate whether any sector in the corresponding extent has been changed or has not changed since the last backup (comparison corresponding identifier information). This indicates the “second identifier information” is the bitmap bits per extent. The “verification result” is the post-validation determination as changed or unchanged based on that bitmap. The “normal/abnormal” is the labeling of the changed/not changed state implied by validated bitmap.
As per claim 8: The method according to claim 2, wherein each of the at least two corresponding files comprises one of the first storage regions, one of the second storage regions, one of the third storage regions, and a fourth storage region; each of the third storage regions stores a record of data updated at each time; and the fourth storage region stores real data of the virtual machine.
Dornemann discloses [Fig. 5; col. 49, lines 30-67] receiving a write operation and modifying change block bitmap indicating the first sector is modified. For each extent that has changed, the entries in the bitmap file are modified and the write operation is performed. This indicates that when states are appropriate, the write operations proceed. The data goes to the virtual hard disk (target data) and the bitmap file is updated (the second corresponding file). It is clear that the plurality of files have a plurality of storage regions for the corresponding files.
As per claim 10: The method according to claim 4, wherein the at least two corresponding files are primary and backup files each other.
Muth discloses [Figs. 7-9; col 14-16] performing file/volume consistency checks by maintaining and comparing status/metadata across mirrored copies (backup files of primary).
As per claim 11: The method according to claim 10, wherein the method further comprises:
determining whether the at least two corresponding files belong to a same group of primary and backup files;
in response to the verification result being normal, determining that the at least two corresponding files belong to the same group of primary and backup files; and
in response to if the verification result being abnormal, determining that the at least two corresponding files do not belong to the same group of primary and backup files.
Muth discloses [Fig. 5; col. 11] the file system determines whether a file modifications have been successfully completed to all mirrors. If synchronization is successful across all mirrors, the file is confirmed to belong to the same mirrored group. When dirty file information shows successful synchronization across mirrors (normal verification result), files are confirmed as belonging to the same primary/backup group. The abnormal verification result (inconsistent state across mirrors) indicates files do not belong to the same mirrored group.
As per claim 12: The method according to claim 3, wherein in a data storage process, a situation in which the virtual machine is run abnormally comprises a device, except the virtual machine, being shut down or halted.
Dornemann discloses [col. 50, lines 58-67] the driver may be configured to intercept VSS freeze and thaw events to control when to pause (halt) changes to the virtual hard disk file (pausing data when the changes are not appropriate/abnormal).
As per claim 19: Although claim 19 is directed towards a device claim, it is rejected under the same rationale as the method claim 1 above.
As per claim 20: Although claim 20 is directed towards a computer-readable medium claim, it is rejected under the same rationale as the method claim 1 above.
As per claim 21: The method according to claim 10, wherein the metadata information comprises a size of a virtual disk and names of the primary and backup files.
Dornemann discloses [Fig. 1B; col. 13-14] teaches metadata including file name and size stored with virtual disk data. The metadata shows “file name” and “data object size” as metadata components, covering both primary file names and backup file names as metadata information.
Claims 9 and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Dornemann in view of Muth and further in view of Cummings (US 8,065,489 B1).
As per claim 9: The method according to claim 2, wherein the third storage regions comprise New unique identifier code (uuid), Bitmap uuid, Last uuid, and History uuid;
the New uuid is uuid information generated when current latest metadata changes;
the Bitmap uuid is uuid information generated by bitmap of a current third storage region;
the Last uuid is uuid information generated when last metadata changes; and
the History uuid is uuid information generated when last two pieces of metadata change.
Dornemann and Muth disclose the method of claim 2, but fail to explicitly disclose unique identifier code for new, bitmap, last, and history identifier. Cummings discloses a similar method, which further teaches [Abstract; col. 5, lines 47-67; col. 4, lines 52-65] the synchronization data is configured to distinguish between a current generation (new/current uuid) and a previous generation (last uuid) of the bitmap. The generation field is tied to the bitmap command structure, teaching that bitmap uuid is generated with the bitmap itself. The synchronization data may include multiple previous generation identifiers to indicate several previous generations (history uuid) for history tracking across multiple metadata change events.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Dornemann and Muth with that of Cummings. One would have been motivated to store a plurality of uuid because it allows to distinguish between a current generation and a previous generation of the bitmap [Cummings; Abstract].
As per claim 13: The method according to claim 9, wherein the method further comprises:
in response to the New uuid of the at least two corresponding files being empty, loading the at least two corresponding files to a virtual machine progress.
Cummings discloses [col. 6, lines 51-67] when generation identifiers are absent or in a special state (analogous to empty), the system performs different handling logic, establishing a basis for initializing/loading behavior.
As per claim 14: The method according to claim 9, wherein the method further comprises:
in response to the New uuid of a first file of the at least two corresponding files being consistent with the Last uuid or the History uuid in a second file of the at least two corresponding files, synchronizing data of the second file to the first file.
Cummings discloses [Fig. 2; col. 5] when current generation matches, the system automatically performs synchronization/update actions. This directly teaches synchronizing data of the second file to the first file upon uuid consistency.
As per claim 15: The method according to claim 9, wherein the method further comprises:
in response to the New uuid of a first file of the at least two corresponding files being inconsistent with the Last uuid or the History uuid in a second file of the at least two corresponding files, manually verifying and synchronizing related data.
Cummings discloses [col. 6, lines 35-65] if the generation identifier in the command is not the same as the identifier for the current generation in the state information, the storage server may take various actions, such as a no operation NOP, stop execution, or do nothing. The NO-OP, stopping execution, or sending notification establishes the manual verification for inconsistency handling.
Allowable Subject Matter
Claims 6, 7, 16, and 17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claim 6 is allowable under the cited prior art references (Dornemann, Muth, Cummings, Ruslyakov) because the references fail to specifically teach to send target data to an abnormal file despite repeated failures and determining that the data storage path itself is abnormal based on a threshold count of failed transmission attempts. The cited references focus on virtual machine backup operations using delta bitmaps and mirror synchronization consistency recovery. While the prior art references teach detecting abnormal files, claim 6 requires specific logic that treating a file as abnormal triggers continued transmission attempts up to a threshold, after which the storage path is determined to be abnormal, which the references fail to disclose alone or in combination. Claims 7, 16, and 17 are objected to be allowable because they are further dependent from claim 6.
Conclusion
The following prior art made of record and not relied upon is cited to establish the level of skill in the applicant’s art and those arts considered reasonably pertinent to applicant’s disclosure. See MPEP 707.05(c).
· US 2022/0391094 A1 – Jain discloses organizing storage as a part of storage regions in virtual machines, each storage region having a fixed size, and for each storage region, storing a storage allocation structure formatted in specific formats.
· US 11,526,403 B1 – Ruslyakov discloses using a storage path to facilitate disaster recovery to a cloud storage device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIGAR P PATEL whose telephone number is (571)270-5067. The examiner can normally be reached on Monday to Friday 10AM-6PM.
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, Ashish Thomas, can be reached on 571-272-0631. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JIGAR P PATEL/Primary Examiner, Art Unit 2114