DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 01/02/2026 has been entered.
Response to Amendment
The amendment filed 01/02/2026 has been entered. Applicant has amended claims 1, 14, and 19. Claim 20 has been cancelled. Claim 21 has been added. Claims 1-19 and 21 are currently pending in the instant application.
Response to Arguments
Applicant’s arguments, see pages 10-14, filed 01/02/2026, with respect to the rejection(s) of claim(s) 1-20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in further view of Talagala et al (US-20190251067-A1). Talagala teaches the amended limitations as seen in the current rejection below.
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.
Claim(s) 1-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Botelho et al (US 2022/0374519) in view of Dayal et al (US 11,086,545) and Talagala et al (US-20190251067-A1).
Regarding claim 1, Botelho teaches A method, comprising: identifying, from among a plurality of snapshot files of a computing object stored at a data management system (DMS), that a first snapshot file representing a first state of the computing object at a first point-in-time is expired, wherein the first snapshot file is partitioned into a first set of data portions stored at a first set of storage locations at the DMS, and wherein a second snapshot file representing a second state of the computing object at a second point-in-time is partitioned into a second set of data portions stored at a second set of storage locations at the DMS ([0084] In one example, a data management application running on a storage appliance, such as storage appliance 140 in FIG. 1 or storage appliance 170 in FIG. 1, may request a snapshot of a virtual machine running on server 160. The snapshot of the virtual machine may be stored as one or more files, with each file associated with a virtual disk of the virtual machine. A snapshot of a virtual machine may correspond with a state of the virtual machine at a particular point in time. The particular point in time may be associated with a time stamp. In one example, a first snapshot of a virtual machine may correspond with a first state of the virtual machine (including the state of applications and files stored on the virtual machine) at a first point in time and a second snapshot of the virtual machine may correspond with a second state of the virtual machine at a second point in time subsequent to the first point in time.); and generating, based at least in part on identifying that the first snapshot file is expired, from the first snapshot file and the second snapshot file, a third snapshot file representing the second state of the computing object at the second point-in-time ((0085] In response to a request for a snapshot of a virtual machine at a particular point in time, the virtualized infrastructure manager 199 may set the virtual machine into a frozen state or store a copy of the virtual machine at the particular point in time. The virtualized infrastructure manager 199 may then transfer data associated with the virtual machine (e.g., an image of the virtual machine or a portion of the image of the virtual machine) to the storage appliance. The data associated with the virtual machine may include a set of files including a virtual disk file storing contents of a virtual disk of the virtual machine at the particular point in time and a virtual machine configuration file storing configuration settings for the virtual machine at the particular point in time. The contents of the virtual disk file may include the operating system used by the virtual machine, local applications stored on the virtual disk, and user files (e.g., images and word processing documents). In some cases, the virtualized infrastructure manager 199 may transfer a full image of the virtual machine to the storage appliance or a plurality of data blocks corresponding with the full image (e.g., to enable a full image-level backup of the virtual machine to be stored on the storage appliance). In other cases, the virtualized infrastructure manager 199 may transfer a portion of an image of the virtual machine associated with data that has changed since an earlier point in time prior to the particular point in time or since a last snapshot of the virtual machine was taken. In one example, the virtualized infrastructure manager 199 may transfer only data associated with virtual blocks stored on a virtual disk of the virtual machine that have changed since the last snapshot of the virtual machine was taken), wherein:the third snapshot file is partitioned into a third set of data portions, one or more first data portions of the third set of data portions being stored at one or more storage locations within the first set of storage locations and one or more second data portions of the third set of data portions being stored at one or more storage locations within the second set of storage locations) [0094] The distributed file system 112 may present itself as a single file system, in which as new physical machines or nodes are added to the storage appliance 170, the cluster may automatically discover the additional nodes and automatically increase the available capacity of the file system for storing files and other data. Each file stored in the distributed file system 112 may be partitioned into one or more chunks or shards. Each of the one or more chunks may be stored within the distributed file system 112 as a separate file. The files stored within the distributed file system 112 may be replicated or mirrored over a plurality of physical machines, thereby creating a load-balanced and fault tolerant distributed file system. In one example, storage appliance 170 may include ten physical machines arranged as a failover cluster and a first file corresponding with a snapshot of a virtual machine (e.g., /snapshotsWM_A/s1/s1.full) may be replicated and stored on three of the ten machines.. )
Botelho does not explicitly teach and generating, based at least in part on identifying that the first snapshot file is expired, from the first snapshot file and the second snapshot file, a third snapshot file representing the second state of the computing object at the second point-in-time in accordance with a reuse consolidation technique, wherein:the third snapshot file is partitioned into a third set of data portions, one or more first data portions of the third set of data portions being stored at one or more reused storage locations within the first set of storage locations and one or more second data portions of the third set of data portions being stored at one or more reused storage locations within the second set of storage locations.
Dayal teaches and generating, based at least in part on identifying that the first snapshot file is expired, from the first snapshot file and the second snapshot file, a third snapshot file representing the second state of the computing object at the second point-in-time in accordance with a reuse consolidation technique, wherein:the third snapshot file is partitioned into a third set of data portions, one or more first data portions of the third set of data portions being stored at one or more reused storage locations within the first set of storage locations and one or more second data portions of the third set of data portions being stored at one or more reused storage locations within the second set of storage locations. (Col 15 lines 30-50; The example cloud replication snapshot table shown in FIG. 7 groups snapshots that have been uploaded to the bucket by their respective VM IDs. Three snapshots (S0, S1, and S2) of VM A have been uploaded to the bucket. For snapshot S0, the cloud replication snapshot table shows that S0 is its snapshot global ID, that the instance of replication of snapshot S0 to the bucket was associated with job ID=26, that snapshot S0 was not deduplicated against an existing snapshot in the bucket (and therefore was sent as a collapsed, not deduplicated snapshot), and that its current storage state at the bucket is live (meaning that the snapshot is to be reclaimed or already reclaimed). For snapshot S1, the cloud replication snapshot table shows that S1 is its snapshot global ID, that the instance of replication of snapshot S1 to the bucket was associated with job ID=27, that snapshot S1 was deduplicated against snapshot S0 of VM A that was already in the bucket (because it was uploaded previously), and that its current storage state at the bucket is live (meaning that the snapshot is not yet reclaimed). For snapshot S3, the cloud replication snapshot table shows that S3 is its snapshot global ID, that the instance of replication of snapshot S3 to the bucket was associated with job ID=28, that snapshot S2 was deduplicated against snapshot S1 of VM A that was already in the bucket (because it was uploaded previously), and that its current storage state at the bucket is live (meaning that the snapshot is not yet reclaimed). One snapshot (S4) of VM B has been uploaded to the bucket. For snapshot S4, the cloud replication snapshot table shows that S4 is its snapshot global ID, that the instance of replication of snapshot S4 to the bucket was associated with job ID=40, that snapshot S4 was deduplicated against snapshot S2 of VM A that was already in the bucket (because it was uploaded previously), and that its current storage state at the bucket is live (meaning that the snapshot is not yet reclaimed). Because snapshot S4, belonging to VM B, was deduplicated against snapshot S2 of VM A during its replication, it is implied that VM B is a clone that was generated from snapshot S2 of VM A, which makes snapshot S2 the shared snapshot and also the base snapshot for snapshot S4 for deduplication purposes.)
Accordingly, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have modified the teachings of Botelho to include generating, based at least in part on identifying that the first snapshot file is expired, from the first snapshot file and the second snapshot file, a third snapshot file representing the second state of the computing object at the second point-in-time in accordance with a reuse consolidation technique, wherein:the third snapshot file is partitioned into a third set of data portions, one or more first data portions of the third set of data portions being stored at one or more reused storage locations within the first set of storage locations and one or more second data portions of the third set of data portions being stored at one or more reused storage locations within the second set of storage locations as taught by Dayal. It would be advantageous since the system is able to consolidate storage and have more available memory as taught by the cited sections of Dayal.
Botelho in view of Dayal does not explicitly teach wherein:the third snapshot file is partitioned into a third set of data portions, one or more first data portions of the third set of data portions being stored at one or more reused storage locations within the first set of storage locations that correspond to the expired first snapshot file,
Talagala teaches wherein:the third snapshot file is partitioned into a third set of data portions, one or more first data portions of the third set of data portions being stored at one or more reused storage locations within the first set of storage locations that correspond to the expired first snapshot file,( [0099] While the log storage module 302 writes data sequentially to a sequential, log-based writing structure, in certain embodiments, maintenance operations, such as a storage capacity recovery operation or the like, may interfere with the sequential order, causing certain data to become out of order. In one embodiment, the temporal order module 402 described below with regard to FIG. 4 preserves a temporal order of the data in the sequential, log-based writing structure, even in the presence of interfering maintenance operations or the like. One embodiment of a storage capacity recovery module 414 is described below with regard to FIG. 4. In general, the storage capacity recovery module 414 recovers storage capacity of the sequential, log-based writing structure by copying or otherwise writing certain data from a selected storage region (e.g., a logical or physical erase block) forward to an append point of the sequential, log-based writing structure (e.g., a new or different storage region) to preserve the data and erasing the selected storage region so that the selected storage region may be reused to store different data. AND [0100]).
Accordingly, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have modified the teachings of Botelho in view of Dayal to include wherein:the third snapshot file is partitioned into a third set of data portions, one or more first data portions of the third set of data portions being stored at one or more reused storage locations within the first set of storage locations that correspond to the expired first snapshot file as taught by Talagala. It would be advantageous since the system is able to reuse storage and have more available memory than storing the snapshot with expired snapshots as taught by the cited sections of Talagala.
Regarding claim 2, Botelho in view of Dayal and Talagala teaches The method of claim 1, Botelho further teaches further comprising: generating, prior to the first snapshot file being expired, the plurality of snapshot files for the computing object, the plurality of snapshot files comprising at least one full snapshot file and a plurality of incremental snapshot files, wherein the plurality of incremental snapshot files comprises the first snapshot file and the second snapshot file ([0096] In some cases, the distributed metadata store 110 may be used to manage one or more versions of a virtual machine. Each version of the virtual machine may correspond with a full image snapshot of the virtual machine stored within the distributed file system 112 or an incremental snapshot of the virtual machine (e.g., a forward incremental or reverse incremental) stored within the distributed file system 112. In one example, the one or more versions of the virtual machine may correspond with a plurality of files. The plurality of files may include a single full image snapshot of the virtual machine and one or more incremental aspects derived from the single full image snapshot. The single full image snapshot of the virtual machine may be stored using a first storage device of a first type (e.g., an HDD) and the one or more incremental aspects derived from the single full image snapshot may be stored using a second storage device of a second type (e.g., an SSD).).
Regarding claim 3, Botelho in view of Dayal and Talagala The method of claim 1, Botelho further teaches further comprising: determining, based at least in part on the first snapshot file being expired, that the first snapshot file stores first data for restoring the computing object to the second point- in-time and the second snapshot file stores second data for restoring the computing object to the second point-in-time; and consolidating, based at least in part on the first snapshot file and the second snapshot file both storing data for restoring the computing object to the second point-in-time, the first data in the first snapshot file and the second data in the second snapshot file, wherein the third snapshot file is generated based at least in part on the consolidating. ([0097] The distributed job scheduler 108 may be used for scheduling backup jobs that acquire and store virtual machine snapshots for one or more virtual machines over time. The distributed job scheduler 108 may follow a backup schedule to back up an entire image of a virtual machine at a particular point in time or one or more virtual disks associated with the virtual machine at the particular point in time. In one example, the backup schedule may specify that the virtual machine be backed up at a snapshot capture frequency, such as every two hours or every 24 hours. Each backup job may be associated with one or more tasks to be performed in a sequence.)
Regarding claim 4, Botelho in view of Dayal and Talagala The method of claim 1, Botelho further teaches further comprising: selecting, based at least in part on the first snapshot file being expired and on both the first snapshot file and the second snapshot file storing data for restoring the computing object to the second point-in-time, a consolidation technique to generate the third snapshot file, wherein selection of the consolidation technique is between at least:a reuse consolidation technique that is associated with including references to one or more of the first set of data portions at the first set of storage locations and to one or more of the second set of data portions at the second set of storage locations in the third snapshot file; and a copy consolidation technique that is associated with copying, to a third set of storage locations associated with the third snapshot file, data blocks in one or more of the first set of data portions from the first set of storage locations and data blocks in the second set of data portions from the second set of storage locations ([0098] The distributed job scheduler 108 may comprise a distributed fault tolerant job scheduler, in which jobs affected by node failures are recovered and rescheduled to be run on available nodes. In one examples, the distributed job scheduler 108 may be fully decentralized and implemented without the existence of a master node. The distributed job scheduler 108 may run job scheduling processes on each node in a cluster or on a plurality of nodes in the cluster. In one example, the distributed job scheduler 108 may run a first set of job scheduling processes on a first node in the cluster, a second set of job scheduling processes on a second node in the cluster, and a third set of job scheduling processes on a third node in the cluster. The first set of job scheduling processes, the second set of job scheduling processes, and the third set of job scheduling processes may store information regarding jobs,).
Regarding claim 5, Botelho in view of Dayal and Talagala The method of claim 4, Botelho further teaches further comprising: calculating, based at least in part on the first snapshot file and the second snapshot file, a sequentiality of a potential snapshot file that consolidates the data for restoring the computing object, wherein the reuse consolidation technique is selected to generate the third snapshot file based at least in part on the sequentiality of the potential snapshot file exceeding a threshold. ([0106] In one example, as each snapshot of a virtual machine is ingested, each virtual disk associated with the virtual machine is parsed in order to identify a file system type associated with the virtual disk and to extract metadata (e.g., file system metadata) for each file stored on the virtual disk. The metadata may include information for locating and retrieving each file from the virtual disk. The metadata may also include a name of a file, the size of the file, the last time at which the file was modified, and a content checksum for the file. Each file that has been added, deleted, or modified since a previous snapshot was captured may be determined using the metadata (e.g., by comparing the time at which a file was last modified with a time associated with the previous snapshot). Thus, for every file that has existed within any of the snapshots of the virtual machine, a virtual machine search index may be used to identify when the file was first created (e.g., corresponding with a first version of the file) and at what times the file was modified (e.g., corresponding with subsequent versions of the file). Each version of the file may be mapped to a particular version of the virtual machine that stores that version of the file.
Regarding claim 6, Botelho in view of Dayal and Talagala The method of claim 1, Botelho further teaches further comprising: determining, based at least in part on the first snapshot file being expired and further based at least in part on to the third snapshot file being generated via a reuse consolidation technique, that a set of data blocks in a first data portion of the first set of data portions of the first snapshot file is to be included in the third snapshot file, the first data portion being stored at a first storage location of the first set of storage locations; and selecting, based at least in part on determining that the set of data blocks in the first data portion is to be included in the third snapshot file, an inclusion technique for including the set of data blocks in the third snapshot file, wherein selection of the inclusion technique is between at least: a first inclusion technique that comprises including, in the third snapshot file, a reference to the first storage location storing the first data portion; and a second inclusion technique that comprises copying the set of data blocks to one or more third data portions of the third set of data portions stored at one or more third storage locations at the DMS, wherein the third snapshot file is generated in accordance with the inclusion technique that is selected. ([0106] In one example, as each snapshot of a virtual machine is ingested, each virtual disk associated with the virtual machine is parsed in order to identify a file system type associated with the virtual disk and to extract metadata (e.g., file system metadata) for each file stored on the virtual disk. The metadata may include information for locating and retrieving each file from the virtual disk. The metadata may also include a name of a file, the size of the file, the last time at which the file was modified, and a content checksum for the file. Each file that has been added, deleted, or modified since a previous snapshot was captured may be determined using the metadata (e.g., by comparing the time at which a file was last modified with a time associated with the previous snapshot). Thus, for every file that has existed within any of the snapshots of the virtual machine, a virtual machine search index may be used to identify when the file was first created (e.g., corresponding with a first version of the file) and at what times the file was modified (e.g., corresponding with subsequent versions of the file). Each version of the file may be mapped to a particular version of the virtual machine that stores that version of the file.)
Regarding claim 7, Botelho in view of Dayal and Talagala The method of claim 6, Botelho further teaches wherein the first inclusion technique that comprises including the reference to the first storage location in the third snapshot file is selected based at least in part on a percentage of data blocks in the first data portion used for restoring the computing object to the second point-in-time satisfying a threshold percentage . ([0096] In some cases, the distributed metadata store 110 may be used to manage one or more versions of a virtual machine. Each version of the virtual machine may correspond with a full image snapshot of the virtual machine stored within the distributed file system 112 or an incremental snapshot of the virtual machine (e.g., a forward incremental or reverse incremental) stored within the distributed file system 112. In one example, the one or more versions of the virtual machine may correspond with a plurality of files. The plurality of files may include a single full image snapshot of the virtual machine and one or more incremental aspects derived from the single full image snapshot. The single full image snapshot of the virtual machine may be stored using a first storage device of a first type (e.g., an HDD) and the one or more incremental aspects derived from the single full image snapshot may be stored using a second storage device of a second type (e.g., an SSD).).
Regarding claim 8, Botelho in view of Dayal and Talagala The method of claim 6, Botelho further teaches further comprising: marking, based at least in part on including the reference to the first storage location in the third snapshot file, a second set of data blocks in the first data portion as unused for restoring the computing object to the second point-in-time. ([0096] In some cases, the distributed metadata store 110 may be used to manage one or more versions of a virtual machine. Each version of the virtual machine may correspond with a full image snapshot of the virtual machine stored within the distributed file system 112 or an incremental snapshot of the virtual machine (e.g., a forward incremental or reverse incremental) stored within the distributed file system 112. In one example, the one or more versions of the virtual machine may correspond with a plurality of files. The plurality of files may include a single full image snapshot of the virtual machine and one or more incremental aspects derived from the single full image snapshot. The single full image snapshot of the virtual machine may be stored using a first storage device of a first type (e.g., an HDD) and the one or more incremental aspects derived from the single full image snapshot may be stored using a second storage device of a second type (e.g., an SSD).).
Regarding claim 9, Botelho in view of Dayal and Talagala The method of claim 6, Botelho further teaches wherein: a data block of the set of data blocks is also included in a second data portion of the first set of data portions, the second data portion being stored at a second storage location of the first set of storage locations, and the first inclusion technique that comprises including the reference to the first storage location in the third snapshot file is selected based at least in part on a determination to also include, in the third snapshot file, a second reference to the second storage location. ([0106] In one example, as each snapshot of a virtual machine is ingested, each virtual disk associated with the virtual machine is parsed in order to identify a file system type associated with the virtual disk and to extract metadata (e.g., file system metadata) for each file stored on the virtual disk. The metadata may include information for locating and retrieving each file from the virtual disk. The metadata may also include a name of a file, the size of the file, the last time at which the file was modified, and a content checksum for the file. Each file that has been added, deleted, or modified since a previous snapshot was captured may be determined using the metadata (e.g., by comparing the time at which a file was last modified with a time associated with the previous snapshot). Thus, for every file that has existed within any of the snapshots of the virtual machine, a virtual machine search index may be used to identify when the file was first created (e.g., corresponding with a first version of the file) and at what times the file was modified (e.g., corresponding with subsequent versions of the file). Each version of the file may be mapped to a particular version of the virtual machine that stores that version of the file.)
Regarding claim 10, Botelho in view of Dayal and Talagala The method of claim 1, Botelho further teaches wherein the first snapshot file is associated with a full snapshot of the computing object and the second snapshot file is associated with an incremental snapshot of the computing object. ([0096] In some cases, the distributed metadata store 110 may be used to manage one or more versions of a virtual machine. Each version of the virtual machine may correspond with a full image snapshot of the virtual machine stored within the distributed file system 112 or an incremental snapshot of the virtual machine (e.g., a forward incremental or reverse incremental) stored within the distributed file system 112. In one example, the one or more versions of the virtual machine may correspond with a plurality of files. The plurality of files may include a single full image snapshot of the virtual machine and one or more incremental aspects derived from the single full image snapshot. The single full image snapshot of the virtual machine may be stored using a first storage device of a first type (e.g., an HDD) and the one or more incremental aspects derived from the single full image snapshot may be stored using a second storage device of a second type (e.g., an SSD).).
Regarding claim 11, Botelho in view of Dayal and Talagala The method of claim 1, Botelho further teaches further comprising: deleting, based at least in part on generating the third snapshot file, a reference to the first snapshot file and a reference to the second snapshot file from a file system of the DMS, wherein, after the reference to the first snapshot file and the reference to the second snapshot file are deleted from the file system:the one or more storage locations within the first set of storage locations storing one or more first data portions of the first set of data portions of the first snapshot file remain valid, the one or more storage locations within the second set of storage locations storing one or more first data portions of the second set of data portions of the second snapshot file remain valid, one ormore second storage locations within the first set of storage locations storing one ormore second data portions of the first set of data portions of the first snapshot file become invalid, and one ormore second storage locations within the second set of storage locations storing one or more second data portions of the second set of data portions of the second snapshot file become invalid. ([0096] In some cases, the distributed metadata store 110 may be used to manage one or more versions of a virtual machine. Each version of the virtual machine may correspond with a full image snapshot of the virtual machine stored within the distributed file system 112 or an incremental snapshot of the virtual machine (e.g., a forward incremental or reverse incremental) stored within the distributed file system 112. In one example, the one or more versions of the virtual machine may correspond with a plurality of files. The plurality of files may include a single full image snapshot of the virtual machine and one or more incremental aspects derived from the single full image snapshot. The single full image snapshot of the virtual machine may be stored using a first storage device of a first type (e.g., an HDD) and the one or more incremental aspects derived from the single full image snapshot may be stored using a second storage device of a second type (e.g., an SSD).).
Regarding claim 12, Botelho in view of Dayal and Talagala The method of claim 11, Botelho further teaches further comprising: erasing, based at least in part on the one or more second storage locations within the first set of storage locations and the one or more second storage locations within the second set of storage locations being marked as invalid, during a garbage collection operation, the one ormore second data portions of the first set of data portions of the first snapshot file from the one or more second storage locations within the first set of storage locations and the one or more second data portions of the second set of data portions of the second snapshot file from the one or more second storage locations within the second set of storage locations. ([0106] In one example, as each snapshot of a virtual machine is ingested, each virtual disk associated with the virtual machine is parsed in order to identify a file system type associated with the virtual disk and to extract metadata (e.g., file system metadata) for each file stored on the virtual disk. The metadata may include information for locating and retrieving each file from the virtual disk. The metadata may also include a name of a file, the size of the file, the last time at which the file was modified, and a content checksum for the file. Each file that has been added, deleted, or modified since a previous snapshot was captured may be determined using the metadata (e.g., by comparing the time at which a file was last modified with a time associated with the previous snapshot). Thus, for every file that has existed within any of the snapshots of the virtual machine, a virtual machine search index may be used to identify when the file was first created (e.g., corresponding with a first version of the file) and at what times the file was modified (e.g., corresponding with subsequent versions of the file). Each version of the file may be mapped to a particular version of the virtual machine that stores that version of the file.)
Regarding claim 13, Botelho in view of Dayal and Talagala The method of claim 1, Botelho further teaches further comprising: receiving, based at least in part on generating the third snapshot file, a request to restore the computing object to the second point-in-time; accessing,in response to the request, the third snapshot file, wherein accessing the third snapshot file comprises:reading the one or more first data portions of the third set of data portions of the third snapshot file from the one or more storage locations within the first set of storage locations, the one or more second data portions of the third set of data portions from the one or more storage locations within the second set of storage locations, and one or more third data portions of the third set of data portions from a third set of storage locations at the DMS; and restoring, after accessing the third snapshot file, the computing object to the second point-in-time in accordance with the third snapshot file. [0094] The distributed file system 112 may present itself as a single file system, in which as new physical machines or nodes are added to the storage appliance 170, the cluster may automatically discover the additional nodes and automatically increase the available capacity of the file system for storing files and other data. Each file stored in the distributed file system 112 may be partitioned into one or more chunks or shards. Each of the one or more chunks may be stored within the distributed file system 112 as a separate file. The files stored within the distributed file system 112 may be replicated or mirrored over a plurality of physical machines, thereby creating a load-balanced and fault tolerant distributed file system. In one example, storage appliance 170 may include ten physical machines arranged as a failover cluster and a first file corresponding with a snapshot of a virtual machine (e.g., /snapshotsWM_A/s1/s1.full) may be replicated and stored on three of the ten machines..
Claims 14-20 are rejected using similar reasoning seen in the current rejection above for claims 1-13 due to reciting similar limitations but directed to different statutory categories.
Allowable Subject Matter
Claim 21 is 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.
The following is a statement of reasons for the indication of allowable subject matter:
Botelho generally teaches a recovery in the event of a ransomware attack on a compute infrastructure. More specifically, some examples include techniques for application migration in cloud data management, ransomware recovery, and mitigation of lost data.
Dayal generally teaches to restore a snapshot from a replication destination to a storage system is received. At least a subset of data associated with the snapshot that is already present at the storage system is determined. A restore operation of the snapshot is performed by obtaining the at least subset of the data associated with the snapshot that is already present at the storage system locally from the storage system and by obtaining the remaining data associated with the snapshot from the replication destination.
Talagala generally teaches snapshots of a non-volatile device. A method includes writing data in a sequential log structure for a non-volatile device. A method includes marking a point, in a sequential log structure, for a snapshot of data. A method includes preserving a logical-to-physical mapping for a snapshot based on a marked point and a temporal order for data in a sequential log structure.
The cited prior art when considered individually or in combination does not disclose the claimed invention.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL SHARPLESS whose telephone number is (571)272-1521. The examiner can normally be reached M-F 7:30 AM- 3:30 PM (ET).
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, ALEKSANDR KERZHNER can be reached at 571-270-1760. 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.
/S.C.S./Examiner, Art Unit 2165
/ALEKSANDR KERZHNER/ Supervisory Patent Examiner, Art Unit 2165
Prosecution Insights