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 .
DETAILED ACTION
This Office Action corresponds to application 19/294,157 which was filed on 8/7/2025 and is a CON of 17/487,935 filed 9/28/2021 which claims benefit of foreign application INDIA 202141034114 filed 7/29/2021. Claims 1-27 are currently pending.
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-2, 5, 8-11, 14, 17-20, 23, and 26-27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chakankar et al. (US2019/0065322), hereinafter Chakankar, in view of Dayal et al. (US2015/0066857), hereinafter Dayal, and Dayal et al. (US11086545), hereinafter Dayal2.
Regarding Claim 1:
Chakankar teaches:
A transactional archival storage system comprising: a frontend data service executing on one or more computing nodes of the system, the frontend data service configured to (i) receive data of a snapshot generated from a logical entity and replicated in a transaction from a client (Chakankar, [0024-0030, 0034-0036, 0048, 0075], note primary system and backup agent; note performing a backup of one or more storage volumes to a secondary storage system; note a full backup or an incremental backup; note backup may be comprised of the data files/blocks/objects of the storage volume; note the first snapshot is addressable via the snapshot tree for that version of the storage volumes; note the snapshots and the tree data structures are generated by a storage system, e.g., primary or secondary storage systems), and (ii) create snapshot metadata describing the snapshot data for persistent storage on storage media local to the frontend data service, the frontend data service further configured to construct an index data structure using the snapshot metadata after receiving a command from the client indicating completion of the transaction (Chakankar, [0024-0032, 0075], note snapshot tree is a tree data structure and is comprised of a root node, one or more levels of intermediate nodes, and one or more leaf nodes; note a leaf node may include a pointer to a file snapshot tree; note storing associated transaction log file segments to the one or more storage volumes of the primary system; note the metadata snapshot tree may be created by a storage system, e.g., local to the frontend); and
a backend data service executing on the one or more computing nodes, the backend data service cooperating with the frontend data service to (iii) store the snapshot data as one or more data objects in an object store of the system (Chakankar, figure 1, [0024-0033, 0048-0050, 0075], note primary system and backup agent; note performing a backup of one or more storage volumes to a secondary storage system), and (iv) store the index data structure in a repository organized according to the snapshot to support location and retrieval of the snapshot data from the one or more data objects in the object store (Chakankar, figures 1 and 4-6, [0024-0033, 0048-0050, 0075], note snapshot trees; note secondary storage system and the file system manager is configured to maintain file system metadata in a file system metadata snapshot tree and database file data; note snapshot trees may be identified and retrieved from a repository according to version/snapshot to retrieve snapshot data);
While Chakankar teaches managing multiple snapshots, Chakankar doesn’t specifically teach creating snapshot metadata describing the snapshot data for persistent storage on storage media local to the frontend data service, the frontend data service further configured to construct an index data structure using the snapshot metadata after receiving a command from the client indicating completion of the transaction. However, However, Dayal is in the same field of endeavor, data management, and Dayal teaches:
A transactional archival storage system comprising: a frontend data service executing on one or more computing nodes of the system, the frontend data service configured to (i) receive data of a snapshot generated from a logical entity and replicated in a transaction from a client (Dayal, figures 1-2 and 4, abstract [0032, 0037-0039], note cloning a snapshot to a destination system. When combined with the previous references the destination system would be the transactional archival storage system as taught by the previous references), and (ii) create snapshot metadata describing the snapshot data for persistent storage on storage media local to the frontend data service, the frontend data service further configured to construct an index data structure using the snapshot metadata after receiving a command from the client indicating completion of the transaction (Dayal, figures 1-2 and 4-5, [0027-0031, 0038-0039], note storing metadata locally; note when creating clones, a new set of metadata is created which includes a new global id, a new snapshot index, and mappings back to the source snapshot, e.g., identifier of the source snapshot and source metadata; note after the clone was created a snapshot index is generated, e.g., upon finalization of the first snapshot and after a first indication of completion of the first transaction. When combined with the previous references this would be for index construction as taught previously); and
a backend data service executing on the one or more computing nodes, the backend data service cooperating with the frontend data service to (iii) store the snapshot data as one or more data objects in an object store of the system, and (iv) store the index data structure in a repository organized according to the snapshot to support location and retrieval of the snapshot data from the one or more data objects in the object store (Dayal, figures 1-2, 4, and 6, [0037-0039, 0061], note storing backups in a secondary storage system);
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal because all references are directed towards data management and because Dayal would expand upon the teachings of the previously cited references in replicating snapshots which would improve efficiency by enabling replicating snapshots and clones to be performed using a minimal amount of information, represented as changes or deltas, and to be transmitted and stored between the replicating storage systems. Any subset of snapshots and clones may be replicated in any order to any system, while preserving a minimal representation of data and metadata on the storage systems (Dayal, [0021]).
While Chakankar teaches as modified teaches managing multiple snapshots, Chakankar as modified is broadly interpreted to use an object store for storage. To further support this interpretation Dayal2 is in the same field of endeavor, data management, and Dayal2 teaches:
A transactional archival storage system comprising: a frontend data service executing on one or more computing nodes of the system, the frontend data service configured to (i) receive data of a snapshot generated from a logical entity and replicated in a transaction from a client, and (ii) create snapshot metadata describing the snapshot data for persistent storage on storage media local to the frontend data service, the frontend data service further configured to construct an index data structure using the snapshot metadata after receiving a command from the client indicating completion of the transaction (Dayal2, figures 1, 3 and 19, column 4 line 45 – column 5 line 16, column 7 lines 13-52, column 8 lines 31-56, note storage systems for snapshots; note storing snapshot metadata, that may be indices corresponding to snapshots, locally and in the object store; note updating data structures after snapshot replication, which is interpreted to mean a command indicating completion); and
a backend data service executing on the one or more computing nodes, the backend data service cooperating with the frontend data service to (iii) store the snapshot data as one or more data objects in an object store of the system, and (iv) store the index data structure in a repository organized according to the snapshot to support location and retrieval of the snapshot data from the one or more data objects in the object store (Dayal2, figures 1 and 3, column 3 line 52 – column 4 line 44, column 7 lines 13-52, column 10 line 58 – column 11 line 3; note generating snapshot objects for snapshot metadata to store in an object store, e.g., repository; note indices support location and retrieval of the snapshot data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
Regarding Claim 2:
Chakankar as modified shows the system as disclosed above;
Chakankar as modified further teaches:
wherein the snapshot data is replicated sequentially in a log-structured format from the client to the frontend data service (Chakankar, [0041-0042, 0046, 0049, 0139-0140], note the use of log sequence numbers for backing up data and transaction logs, which means the replication is occurring sequentially and in a log-structured format) (Dayal, figures 12A, [0093], note sequentially replicating snapshot data) (Dayal2, figure 5, column 4 line 45 – column 5 line 16, note sequentially replicating snapshot data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal because all references are directed towards data management and because Dayal would expand upon the teachings of the previously cited references in replicating snapshots which would improve efficiency by enabling replicating snapshots and clones to be performed using a minimal amount of information, represented as changes or deltas, and to be transmitted and stored between the replicating storage systems. Any subset of snapshots and clones may be replicated in any order to any system, while preserving a minimal representation of data and metadata on the storage systems (Dayal, [0021]).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
Regarding Claim 5:
Chakankar as modified shows the system as disclosed above;
Chakankar as modified further teaches:
wherein the snapshot data is replicated to the frontend data service using replication application program interfaces (APIs) having descriptive semantics (Chakankar, [0064], note the use of APIs) (Dayal2, column 26, lines 21-34, column 35 lines 50-64, note the use of APIs to replicate snapshot data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
Regarding Claim 8:
Chakankar as modified shows the system as disclosed above;
Chakankar as modified further teaches:
wherein the frontend data service is further configured to construct the index data structure in a storage tier local to the frontend data service (Chakankar, [0024-0032, 0075], note snapshot tree is a tree data structure and is comprised of a root node, one or more levels of intermediate nodes, and one or more leaf nodes; note a leaf node may include a pointer to a file snapshot tree; note storing associated transaction log file segments to the one or more storage volumes of the primary system; note the metadata snapshot tree may be created by a storage system, e.g., local to the frontend) (Dayal, figures 1-2 and 4-5, [0027-0031, 0038-0039], note storing metadata locally, e.g., a local storage tier) (Dayal2, figures 1, 3 and 19, column 4 line 45 – column 5 line 16, column 7 lines 13-52, column 8 lines 31-56, note storage systems for snapshots; note storing snapshot metadata, that may be indices corresponding to snapshots, locally and in the object store, e.g., local storage tier; note updating data structures after snapshot replication, which is interpreted to mean a command indicating completion)
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal because all references are directed towards data management and because Dayal would expand upon the teachings of the previously cited references in replicating snapshots which would improve efficiency by enabling replicating snapshots and clones to be performed using a minimal amount of information, represented as changes or deltas, and to be transmitted and stored between the replicating storage systems. Any subset of snapshots and clones may be replicated in any order to any system, while preserving a minimal representation of data and metadata on the storage systems (Dayal, [0021]).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
Regarding Claim 9:
Chakankar as modified shows the system as disclosed above;
Chakankar as modified further teaches:
wherein the repository is a snapshot configuration repository organized as a key-value store that provides indexing to resolve to the snapshot corresponding to the index data structure (Chakankar, figures 3A-3E, [0024-0033, 0077, 0099], note the use of key-value pairs stored in the snapshot trees that provide indexing to the snapshot) (Dayal2, column 17 lines 3-9, note key-value based object stores).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
Regarding Claim 10:
Chakankar teaches:
A method comprising: replicating data of a snapshot generated from a logical entity at a client, the snapshot data replicated in a transaction from the client to a data service executing on one or more computing nodes of a transactional archival storage system (Chakankar, [0024-0030, 0034-0036, 0048, 0075], note primary system and backup agent; note performing a backup of one or more storage volumes to a secondary storage system; note a full backup or an incremental backup; note backup may be comprised of the data files/blocks/objects of the storage volume; note the first snapshot is addressable via the snapshot tree for that version of the storage volumes; note the snapshots and the tree data structures are generated by a storage system, e.g., primary or secondary storage systems);
organizing the snapshot data as one or more data objects for storage by the data service in an object store of the archival storage system (Chakankar, figure 1, [0024-0033, 0048-0050, 0075], note primary system and backup agent; note performing a backup of one or more storage volumes to a secondary storage system);
persistently storing snapshot metadata describing the snapshot data on storage media local to the data service (Chakankar, [0024-0032, 0075], note snapshot tree is a tree data structure and is comprised of a root node, one or more levels of intermediate nodes, and one or more leaf nodes; note a leaf node may include a pointer to a file snapshot tree; note storing associated transaction log file segments to the one or more storage volumes of the primary system; note the metadata snapshot tree may be created by a storage system, e.g., local); and
constructing an index data structure at the data service using the snapshot metadata after (i) receiving a command from the client indicating completion of the transaction by the client and (ii) all of the snapshot data is stored in the object store, wherein the index data structure is stored in a repository organized according to the snapshot to support location and retrieval of the snapshot data from the one or more data objects in the object store (Chakankar, figures 1 and 4-6, [0024-0033, 0048-0050, 0075], note snapshot tree is a tree data structure and is comprised of a root node, one or more levels of intermediate nodes, and one or more leaf nodes; note a leaf node may include a pointer to a file snapshot tree; note storing associated transaction log file segments to the one or more storage volumes of the primary system; note the metadata snapshot tree may be created by a storage system, e.g., local; note secondary storage system and the file system manager is configured to maintain file system metadata in a file system metadata snapshot tree and database file data; note snapshot trees may be identified and retrieved from a repository according to version/snapshot to retrieve snapshot data).
While Chakankar teaches managing multiple snapshots, Chakankar doesn’t specifically teach creating persistently storing snapshot metadata describing the snapshot data on storage media local to the data service; constructing an index data structure at the data service using the snapshot metadata after (i) receiving a command from the client indicating completion of the transaction by the client. However, Dayal is in the same field of endeavor, data management, and Dayal teaches:
A method comprising: replicating data of a snapshot generated from a logical entity at a client, the snapshot data replicated in a transaction from the client to a data service executing on one or more computing nodes of a transactional archival storage system (Dayal, figures 1-2 and 4, abstract [0032, 0037-0039], note cloning a snapshot to a destination system. When combined with the previous references the destination system would be the transactional archival storage system as taught by the previous references);
organizing the snapshot data as one or more data objects for storage by the data service in an object store of the archival storage system (Dayal, figures 1-2, 4, and 6, [0037-0039, 0061], note storing backups in a secondary storage system);
persistently storing snapshot metadata describing the snapshot data on storage media local to the data service (Dayal, figures 1-2 and 4-5, [0027-0031, 0038-0039], note storing metadata locally)
constructing an index data structure at the data service using the snapshot metadata after (i) receiving a command from the client indicating completion of the transaction by the client and (ii) all of the snapshot data is stored in the object store, wherein the index data structure is stored in a repository organized according to the snapshot to support location and retrieval of the snapshot data from the one or more data objects in the object store (Dayal, figures 1-2 and 4-5, [0027-0031, 0038-0039], note storing metadata locally; note when creating clones, a new set of metadata is created which includes a new global id, a new snapshot index, and mappings back to the source snapshot, e.g., identifier of the source snapshot and source metadata; note after the clone was created a snapshot index is generated, e.g., upon finalization of the first snapshot and after a first indication of completion of the first transaction. When combined with the previous references this would be for index construction as taught previously)
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal because all references are directed towards data management and because Dayal would expand upon the teachings of the previously cited references in replicating snapshots which would improve efficiency by enabling replicating snapshots and clones to be performed using a minimal amount of information, represented as changes or deltas, and to be transmitted and stored between the replicating storage systems. Any subset of snapshots and clones may be replicated in any order to any system, while preserving a minimal representation of data and metadata on the storage systems (Dayal, [0021]).
While Chakankar teaches as modified teaches managing multiple snapshots, Chakankar as modified is broadly interpreted to use an object store for storage. To further support this interpretation Dayal2 is in the same field of endeavor, data management, and Dayal2 teaches:
A method comprising: replicating data of a snapshot generated from a logical entity at a client, the snapshot data replicated in a transaction from the client to a data service executing on one or more computing nodes of a transactional archival storage system (Dayal2, figures 1, 3 and 19, column 4 line 45 – column 5 line 16, column 7 lines 13-52, column 8 lines 31-56, note storage systems for snapshots; note storing snapshot metadata, that may be indices corresponding to snapshots, locally and in the object store; note updating data structures after snapshot replication, which is interpreted to mean a command indicating completion);
organizing the snapshot data as one or more data objects for storage by the data service in an object store of the archival storage system (Dayal2, figures 1 and 3, column 3 line 52 – column 4 line 44, column 7 lines 13-52, column 10 line 58 – column 11 line 3; note generating snapshot objects for snapshot metadata to store in an object store, e.g., repository; note indices support location and retrieval of the snapshot data);
persistently storing snapshot metadata describing the snapshot data on storage media local to the data service (Dayal2, figures 1, 3 and 19, column 4 line 45 – column 5 line 16, column 7 lines 13-52, column 8 lines 31-56, note storage systems for snapshots; note storing snapshot metadata, that may be indices corresponding to snapshots, locally and in the object store; note updating data structures after snapshot replication, which is interpreted to mean a command indicating completion);
constructing an index data structure at the data service using the snapshot metadata after (i) receiving a command from the client indicating completion of the transaction by the client and (ii) all of the snapshot data is stored in the object store, wherein the index data structure is stored in a repository organized according to the snapshot to support location and retrieval of the snapshot data from the one or more data objects in the object store (Dayal2, figures 1, 3 and 19, column 3 line 52 – column 5 line 16, column 7 lines 13-52, column 8 lines 31-56; column 10 line 58 – column 11 line 3, note storage systems for snapshots; note storing snapshot metadata, that may be indices corresponding to snapshots, locally and in the object store; note updating data structures after snapshot replication, which is interpreted to mean a command indicating completion; note generating snapshot objects for snapshot metadata to store in an object store, e.g., repository; note indices support location and retrieval of the snapshot data)
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
Regarding Claim 11:
Chakankar as modified shows the method as disclosed above;
Chakankar as modified further teaches:
wherein replicating the data of the snapshot comprises replicating the snapshot data sequentially in a log-structured format from the client to the data service (Chakankar, [0041-0042, 0046, 0049, 0139-0140], note the use of log sequence numbers for backing up data and transaction logs, which means the replication is occurring sequentially and in a log-structured format) (Dayal, figures 12A, [0093], note sequentially replicating snapshot data) (Dayal2, figure 5, column 4 line 45 – column 5 line 16, note sequentially replicating snapshot data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal because all references are directed towards data management and because Dayal would expand upon the teachings of the previously cited references in replicating snapshots which would improve efficiency by enabling replicating snapshots and clones to be performed using a minimal amount of information, represented as changes or deltas, and to be transmitted and stored between the replicating storage systems. Any subset of snapshots and clones may be replicated in any order to any system, while preserving a minimal representation of data and metadata on the storage systems (Dayal, [0021]).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
Regarding Claim 14:
Chakankar as modified shows the method as disclosed above;
Chakankar as modified further teaches:
wherein the snapshot data is replicated to the frontend data service using replication application program interfaces (APIs) having descriptive semantics (Chakankar, [0064], note the use of APIs) (Dayal2, column 26, lines 21-34, column 35 lines 50-64, note the use of APIs to replicate snapshot data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
Regarding Claim 17:
Chakankar as modified shows the method as disclosed above;
Chakankar as modified further teaches:
wherein constructing the index data structure comprises: constructing the index data structure in a storage tier local to a front end service of the data service (Chakankar, [0024-0032, 0075], note snapshot tree is a tree data structure and is comprised of a root node, one or more levels of intermediate nodes, and one or more leaf nodes; note a leaf node may include a pointer to a file snapshot tree; note storing associated transaction log file segments to the one or more storage volumes of the primary system; note the metadata snapshot tree may be created by a storage system, e.g., local) (Dayal, figures 1-2 and 4-5, [0027-0031, 0038-0039], note storing metadata locally) (Dayal2, figures 1, 3 and 19, column 4 line 45 – column 5 line 16, column 7 lines 13-52, column 8 lines 31-56, note storage systems for snapshots; note storing snapshot metadata, that may be indices corresponding to snapshots, locally and in the object store; note updating data structures after snapshot replication, which is interpreted to mean a command indicating completion); and
flushing the constructed index structure to a backend service of the data service for storage on the object store (Chakankar, [0024-0032, 0075], note snapshot tree is a tree data structure; note backup agent; note secondary storage system and the file system manager is configured to maintain file system metadata in a file system metadata snapshot tree and database file data) (Dayal, figures 1-2 and 4-5, [0027-0031, 0037-0039, 0061], note storing metadata locally; note when creating clones, a new set of metadata is created which includes a new global id, a new snapshot index, and mappings back to the source snapshot, e.g., identifier of the source snapshot and source metadata; note after the clone was created a snapshot index is generated; note storing backups in a secondary storage system) (Dayal2, figures 1, 3 and 19, column 3 line 52 – column 5 line 16, column 7 lines 13-52, column 8 lines 31-56, note storage systems for snapshots; note storing snapshot metadata, that may be indices corresponding to snapshots, locally and in the object store; note updating data structures after snapshot replication, which is interpreted to mean a command indicating completion; note generating snapshot objects for snapshot metadata to store in an object store, e.g., repository; note indices support location and retrieval of the snapshot data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal because all references are directed towards data management and because Dayal would expand upon the teachings of the previously cited references in replicating snapshots which would improve efficiency by enabling replicating snapshots and clones to be performed using a minimal amount of information, represented as changes or deltas, and to be transmitted and stored between the replicating storage systems. Any subset of snapshots and clones may be replicated in any order to any system, while preserving a minimal representation of data and metadata on the storage systems (Dayal, [0021]).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
Regarding Claim 18:
Chakankar as modified shows the system as disclosed above;
Chakankar as modified further teaches:
wherein the repository is a snapshot configuration repository organized as a key-value store that provides indexing to resolve to the snapshot corresponding to the index data structure (Chakankar, figures 3A-3E, [0024-0033, 0077, 0099], note the use of key-value pairs stored in the snapshot trees that provide indexing to the snapshot) (Dayal2, column 17 lines 3-9, note key-value based object stores).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
Claim 19 discloses substantially the same limitations as claim 10 respectively, except claim 19 is directed to a non-transitory computer readable medium comprising a processors (Chakankar, [0021, note processor) while claim 10 is directed to a method. Therefore claim 19 is rejected under the same rationale set forth for claim 10.
Claim 20 discloses substantially the same limitations as claim 11 respectively, except claim 20 is directed to a non-transitory computer readable medium comprising a processors (Chakankar, [0021, note processor) while claim 11 is directed to a method. Therefore claim 20 is rejected under the same rationale set forth for claim 11.
Claim 23 discloses substantially the same limitations as claim 14 respectively, except claim 23 is directed to a non-transitory computer readable medium comprising a processors (Chakankar, [0021, note processor) while claim 14 is directed to a method. Therefore claim 23 is rejected under the same rationale set forth for claim 14.
Claim 26 discloses substantially the same limitations as claim 17 respectively, except claim 26 is directed to a non-transitory computer readable medium comprising a processors (Chakankar, [0021, note processor) while claim 17 is directed to a method. Therefore claim 26 is rejected under the same rationale set forth for claim 17.
Claim 27 discloses substantially the same limitations as claim 18 respectively, except claim 27 is directed to a non-transitory computer readable medium comprising a processors (Chakankar, [0021, note processor) while claim 18 is directed to a method. Therefore claim 27 is rejected under the same rationale set forth for claim 18.
Claim Rejections - 35 USC § 103
Claim(s) 3-4, 12-13, and 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chakankar in view of Dayal, Dayal2, and Bhardwaj et al. (US9747287), hereinafter Bhardwaj.
Regarding Claim 3:
Chakankar as modified shows the system as disclosed above;
Chakankar as modified further teaches:
wherein the logical entity is a virtual disk (vdisk) and wherein the index data structure functions as a database organized to retrieve the snapshot data by extent of the vdisk (Chakankar, [0024-0033, 0040, 0048-0050, 0075], note performing a backup of one or more storage volumes to a secondary storage system; note a full backup or an incremental backup; note backup may be comprised of the data files/blocks/objects of the storage volume; note the primary system may be a virtual machine, e.g. virtual disk; note the snapshots and the tree data structures are generated by a file system; note snapshot tree is a tree data structure; note snapshot trees may be identified and retrieved from a repository according to version/snapshot to retrieve snapshot data).
While Chakankar as modified teaches the use of vdisks, Chakankar as modified doesn’t specifically state using extents of the vdisk. However, Bhardwaj is in the same field of endeavor, data management, and Bhardwaj teaches:
wherein the logical entity is a virtual disk (vdisk) and wherein the index data structure functions as a database organized to retrieve the snapshot data by extent of the vdisk (Bhardwaj, column 9 lines 24-40 and lines 64-67, note the use of extents of the vdisk for snapshot data. When combined with the previously cited references this would be for the snapshot data as taught by Chakankar and Dayal);
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Bhardwaj because all references are directed towards data management and because Bhardwaj would expand upon the teachings of the previously cited references in managing data using virtualized environments by improving the performance by optimizing the use of the vdisks (Bhardwaj, column 5 lines 28-41).
Regarding Claim 4:
Chakankar as modified shows the system as disclosed above;
Chakankar as modified further teaches:
wherein the snapshot metadata describing the snapshot data comprises (i) a logical offset and range of an extent in the snapshot of the vdisk, and (ii) an object identifier containing the extent and the logical offset within the data object where the extent resides (Chakankar, figure 3E items 370, 372, and 382, [0099], note IDs and data keys) (Bhardwaj, column 9 lines 24-40 and lines 64-67, note the use of extents of the vdisk with offsets; note mapping the address space includes a range; note use of snapshot data; note the extent ID containing the extent and offset. When combined with the previously cited references this would be for the snapshot data as taught by Chakankar and Dayal);
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Bhardwaj because all references are directed towards data management and because Bhardwaj would expand upon the teachings of the previously cited references in managing data using virtualized environments by improving the performance by optimizing the use of the vdisks (Bhardwaj, column 5 lines 28-41).
Regarding Claim 12:
Chakankar as modified shows the method as disclosed above;
Chakankar as modified further teaches:
wherein the logical entity is a virtual disk (vdisk) and wherein the index data structure functions as a database organized to retrieve the snapshot data by extent of the vdisk (Chakankar, [0024-0033, 0040, 0048-0050, 0075], note performing a backup of one or more storage volumes to a secondary storage system; note a full backup or an incremental backup; note backup may be comprised of the data files/blocks/objects of the storage volume; note the primary system may be a virtual machine, e.g. virtual disk; note the snapshots and the tree data structures are generated by a file system; note snapshot tree is a tree data structure; note snapshot trees may be identified and retrieved from a repository according to version/snapshot to retrieve snapshot data).
While Chakankar as modified teaches the use of vdisks, Chakankar as modified doesn’t specifically state using extents of the vdisk. However, Bhardwaj is in the same field of endeavor, data management, and Bhardwaj teaches:
wherein the logical entity is a virtual disk (vdisk) and wherein the index data structure functions as a database organized to retrieve the snapshot data by extent of the vdisk (Bhardwaj, column 9 lines 24-40 and lines 64-67, note the use of extents of the vdisk for snapshot data. When combined with the previously cited references this would be for the snapshot data as taught by Chakankar and Dayal);
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Bhardwaj because all references are directed towards data management and because Bhardwaj would expand upon the teachings of the previously cited references in managing data using virtualized environments by improving the performance by optimizing the use of the vdisks (Bhardwaj, column 5 lines 28-41).
Regarding Claim 13:
Chakankar as modified shows the method as disclosed above;
Chakankar as modified further teaches:
wherein the snapshot metadata describing the snapshot data comprises (i) a logical offset and range of an extent in the snapshot of the vdisk, and (ii) an object identifier containing the extent and the logical offset within the data object where the extent resides (Chakankar, figure 3E items 370, 372, and 382, [0099], note IDs and data keys) (Bhardwaj, column 9 lines 24-40 and lines 64-67, note the use of extents of the vdisk with offsets; note mapping the address space includes a range; note use of snapshot data; note the extent ID containing the extent and offset. When combined with the previously cited references this would be for the snapshot data as taught by Chakankar and Dayal);
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Bhardwaj because all references are directed towards data management and because Bhardwaj would expand upon the teachings of the previously cited references in managing data using virtualized environments by improving the performance by optimizing the use of the vdisks (Bhardwaj, column 5 lines 28-41).
Claim 21 discloses substantially the same limitations as claim 12 respectively, except claim 21 is directed to a non-transitory computer readable medium comprising a processors (Chakankar, [0021, note processor) while claim 12 is directed to a method. Therefore claim 21 is rejected under the same rationale set forth for claim 12.
Claim 22 discloses substantially the same limitations as claim 13 respectively, except claim 22 is directed to a non-transitory computer readable medium comprising a processors (Chakankar, [0021, note processor) while claim 13 is directed to a method. Therefore claim 22 is rejected under the same rationale set forth for claim 13.
Claim Rejections - 35 USC § 103
Claim(s) 6-7, 15-16, and 24-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chakankar in view of Dayal, Dayal2, and Wood (US2005/0033795).
Regarding Claim 6:
Chakankar as modified shows the system as disclosed above;
Chakankar as modified further teaches:
wherein the repository is a snapshot configuration repository and configured to reference a root of the index data structure associated with the one or more data objects (Chakankar, figure 1, [0024-0033, 0048-0050, 0075], note snapshot tree is a tree data structure and is comprised of a root node, one or more levels of intermediate nodes, and one or more leaf nodes; note performing a backup of one or more storage volumes to a secondary storage system; note secondary storage system and the file system manager is configured to maintain file system metadata in a file system metadata snapshot tree and database file data; note snapshot trees may be identified and retrieved from a repository according to version/snapshot to retrieve snapshot data) (Dayal2, figures 1 and 3, column 3 line 52 – column 4 line 44, column 7 lines 13-52, column 10 line 58 – column 11 line 3; note generating snapshot objects for snapshot metadata to store in an object store, e.g., repository; note indices support location and retrieval of the snapshot data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
While Chakankar as modified teaches the use of repositories, Chakankar as modified doesn’t specifically state the snapshot configuration repository managed separately. However, Wood is in the same field of endeavor, data management, and Wood teaches:
wherein the repository is a snapshot configuration repository managed separately from the object store and configured to reference a root of the index data structure associated with the one or more data objects (Wood, [0084], note storing indices in specific repositories. When combined with the previously cited references this would be for the snapshot data as taught by Chakankar and Dayal).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Wood because all references are directed towards data management and because Wood would expand upon the teachings of the previously cited references in managing data by improving accuracy and performance by using improved identification methods (Wood, [0002]).
Regarding Claim 7:
Chakankar as modified shows the system as disclosed above;
Chakankar as modified further teaches:
wherein the reference to the root is a uniform resource locator (URL) to a root node of the index data structure resident on object store media located on a network (Chakankar, figure 1, [0024-0033, 0048-0050, 0075], note snapshot tree is a tree data structure and is comprised of a root node, one or more levels of intermediate nodes, and one or more leaf nodes; note performing a backup of one or more storage volumes to a secondary storage system; note secondary storage system and the file system manager is configured to maintain file system metadata in a file system metadata snapshot tree and database file data; note snapshot trees may be identified and retrieved from a repository according to version/snapshot to retrieve snapshot data) (Wood, [0084], note storing indices in specific repositories; note the use of URLs to references the nodes. When combined with the previously cited references this would be for the snapshot data as taught by Chakankar and Dayal).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Wood because all references are directed towards data management and because Wood would expand upon the teachings of the previously cited references in managing data by improving accuracy and performance by using improved identification methods (Wood, [0002]).
Regarding Claim 15:
Chakankar as modified shows the method as disclosed above;
Chakankar as modified further teaches:
wherein the repository is a snapshot configuration repository and configured to reference a root of the index data structure associated with the one or more data objects (Chakankar, figure 1, [0024-0033, 0048-0050, 0075], note snapshot tree is a tree data structure and is comprised of a root node, one or more levels of intermediate nodes, and one or more leaf nodes; note performing a backup of one or more storage volumes to a secondary storage system; note secondary storage system and the file system manager is configured to maintain file system metadata in a file system metadata snapshot tree and database file data; note snapshot trees may be identified and retrieved from a repository according to version/snapshot to retrieve snapshot data) (Dayal2, figures 1 and 3, column 3 line 52 – column 4 line 44, column 7 lines 13-52, column 10 line 58 – column 11 line 3; note generating snapshot objects for snapshot metadata to store in an object store, e.g., repository; note indices support location and retrieval of the snapshot data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Dayal2 because all references are directed towards data management and because Dayal2 would expand upon the teachings of the previously cited references in replicating snapshots which would improve performance of restoring data by integrating the primary storage snapshot and cloud snapshot (Dayal2, column 1 lines 49-55).
While Chakankar as modified teaches the use of repositories, Chakankar as modified doesn’t specifically state the snapshot configuration repository managed separately. However, Wood is in the same field of endeavor, data management, and Wood teaches:
wherein the repository is a snapshot configuration repository managed separately from the object store and configured to reference a root of the index data structure associated with the one or more data objects (Wood, [0084], note storing indices in specific repositories. When combined with the previously cited references this would be for the snapshot data as taught by Chakankar and Dayal).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Wood because all references are directed towards data management and because Wood would expand upon the teachings of the previously cited references in managing data by improving accuracy and performance by using improved identification methods (Wood, [0002]).
Regarding Claim 16:
Chakankar as modified shows the method as disclosed above;
Chakankar as modified further teaches:
wherein the reference to the root is a uniform resource locator (URL) to a root node of the index data structure resident on object store media located on a network (Chakankar, figure 1, [0024-0033, 0048-0050, 0075], note snapshot tree is a tree data structure and is comprised of a root node, one or more levels of intermediate nodes, and one or more leaf nodes; note performing a backup of one or more storage volumes to a secondary storage system; note secondary storage system and the file system manager is configured to maintain file system metadata in a file system metadata snapshot tree and database file data; note snapshot trees may be identified and retrieved from a repository according to version/snapshot to retrieve snapshot data) (Wood, [0084], note storing indices in specific repositories; note the use of URLs to references the nodes. When combined with the previously cited references this would be for the snapshot data as taught by Chakankar and Dayal).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Wood because all references are directed towards data management and because Wood would expand upon the teachings of the previously cited references in managing data by improving accuracy and performance by using improved identification methods (Wood, [0002]).
Claim 24 discloses substantially the same limitations as claim 15 respectively, except claim 24 is directed to a non-transitory computer readable medium comprising a processors (Chakankar, [0021, note processor) while claim 15 is directed to a method. Therefore claim 24 is rejected under the same rationale set forth for claim 15.
Claim 25 discloses substantially the same limitations as claim 16 respectively, except claim 25 is directed to a non-transitory computer readable medium comprising a processors (Chakankar, [0021, note processor) while claim 16 is directed to a method. Therefore claim 25 is rejected under the same rationale set forth for claim 16.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Negi et al. (US2022/0261386) teaches an object store for snapshot data.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN J MORRIS whose telephone number is (571)272-3314. The examiner can normally be reached M-F 6:00-2:00 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, James Trujillo can be reached at 571-272-3677. 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.
/JOHN J MORRIS/Examiner, Art Unit 2151 6/11/2026
/James Trujillo/Supervisory Patent Examiner, Art Unit 2151
Prosecution Insights