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
The Action is responsive to the Request for Continued Examination and the Amendments filed on 2/27/2026. Claims 1-5, 7-15, 17-18, and 20-23 are pending claims. Claims 1, 14, and 20 are written in independent form. Claims 6, 16, and 19 were previously cancelled.
Priority
Acknowledgment is made of applicant’s claim for foreign priority to IN202211031304, filed 06/01/2022, under 35 U.S.C. § 119(a)-(d). Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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-5, 7-15, 17-18, and 20-23 are rejected under 35 U.S.C. 103 as being unpatentable over Ashutosh et al. (U.S. Patent Pre-Grant Publication No. 2012/0123999, hereinafter referred to as Ashutosh) and further in view of Agarwal (U.S. Patent No. 10,324,803) and Iyer et al. (U.S. Pre-Grant Publication No. 2018/0267861, hereinafter referred to as Iyer).
Regarding Claim 1:
Ashutosh teaches a method, comprising:
Obtaining, at a data management system configured to interface with a computing object, snapshots of the computing object;
Ashutosh performs snapshot functions (i.e., computing object), such as backup, replication, and archiving. A snapshot can be either a copy (i.e., by backup job) from primary storage, or a copy (i.e., by archival job) from secondary storage, to be stored in secondary storage [0036]. SLAs specify snapshot schedules, with each SLA defining a service level policy (i.e., archival policy) identifying parameters such as source and destination pools (i.e., archive locations), copy (i.e., obtention) frequency, retention period, and schedule information [0037].
Tagging, by the data management system, the snapshots with one or more respective frequency parameters based at least in part on obtaining the snapshots,
Wherein the tagged one or more respective frequency parameters are indicative of respective obtention frequencies associated with the snapshots,
Wherein a first snapshot of the snapshots is tagged with both a first frequency parameter of the one or more respective frequency parameters and a second frequency parameter of the one or more respective frequency parameters, and
Wherein the first frequency parameter is different than the second frequency parameter;
Ashutosh performs snapshot functions (i.e., computing object), such as backup, replication, and archiving. A snapshot can be either a copy (i.e., by backup job) from primary storage, or a copy (i.e., by archival job) from secondary storage, to be stored in secondary storage [0036]. SLAs specify snapshot schedules, with each SLA defining a service level policy (i.e., archival policy) identifying parameters such as source and destination pools (i.e., archive locations), copy (i.e., obtention) frequency, retention period, and schedule information [0037].
Tagging, by the data management system, the snapshots with one or more respective archival policy parameters based at least in part on obtaining the snapshots,
Wherein the tagged one or more respective archival policy parameters are different from the tagged one or more respective frequency parameters and are indicative of respective purposes associated with the snapshots,
Wherein the first snapshot of the snapshots is tagged with both a first archival policy parameter of the one or more archival policy parameters and a second archival policy parameter of the one or more archival policy parameters, and
Wherein the first archival policy parameter is a long-term retention parameter and the second archival policy parameter is a disaster recovery parameter;
Ashutosh virtualizes (i.e., identifies) physical storage resources for the snapshot store, including local/primary and remote/secondary storage devices and public/private/hybrid storage clouds, into data protection storage pools for various purposes (i.e., policy parameters) [0041], such as a Quick Recovery Pool for rapid recovery (i.e., disaster recovery parameter), a Cost Efficient Long-term Storage Pool for reduction of archival storage cost (i.e., long-term retention parameter), or a tape library [0042].
Storing, by the data management system, the snapshots tagged with the one or more respective frequency parameters in one or more storage nodes associated with the data management system;
Ashutosh deploys a snapshot store either within a single host, or distributed across a network of multiple hosts (i.e., storage nodes) [0057].
Identifying by the data management system, for the snapshots stored in the one or more storage nodes, and based at least in part on satisfaction of an archival job periodicity parameter for the computing object, one or more respective archive locations from among a set of two or more candidate archive locations based at least in part on the tagged one or more respective frequency parameters and the tagged one or more respective archival policy parameters of the snapshots,
Wherein the identifying comprises identifying a first respective archive location from among the set of two or more candidate archive locations for the first snapshot based at least in part on the first snapshot being tagged with the first frequency parameter and the long-term retention parameter,
Wherein the identifying comprises identifying a second respective archive location from among the set of two or more candidate archive locations for the first snapshot based at least in part on the first snapshot being tagged with the second frequency parameter and the disaster recovery parameter, and
Wherein the first respective archive location is different than the second respective archive location;
Ashutosh characterizes each storage pool by geographic location (i.e., archive location), speed and cost attributes [0063]. Example policies may specify a daily snapshot (i.e., second frequency parameter) to a local backup location (i.e., second location), and a weekly snapshot (i.e., first frequency parameter) to a remote archive location (i.e., first location).
Transmitting, by the data management system and based at least in part on the satisfaction of the archival job periodicity parameter, the snapshots from the one or more storage noes to the one or more respective identified archive locations,
Wherein the transmitting comprises transmitting the first snapshot to both the first respective archive location and the second respective archive location;
Ashutosh teaches a service level policy engine that acts on the SLA to be satisfied to make decisions regarding the creation (i.e., backup/archive), movement (i.e., transmission) and deletion (i.e., expiration) of snapshot copies of data in the snapshot store [0061].
Ashutosh explicitly teaches all of the elements of the claimed invention as recited above except:
tagging snapshots with frequency and retention parameters;
Providing, via a user interface of a computing system and in response to receiving a request to restore the computing object using the first snapshot, a listing of the one or more respective identified archive locations that includes the first respective archive location and the second respective archive location;
Receiving, via the user interface of the computing system and after providing the listing, a selection of either the first respective archive location or the second respective archive location; and
Retrieving the first snapshot from the selected archive location in response to the selection of either the first respective archive location or the second respective archive location.
However, in the related field of endeavor of managing storage snapshots, Agarwal teaches:
tagging snapshots with frequency and retention parameters;
Agarwal tags a computing instance and its assigned storage volume with the applicable storage snapshot policy (Agarwal: 2:25-33), including parameters such as frequency (i.e., periodicity) for how often a snapshot is created (i.e., obtained) from the storage volume, snapshot time, and retention period (Agarwal: fig. 1a; 3:37-48). Upon creation, a snapshot is linked to (i.e., tagged with) a snapshot maintenance record, the record including its snapshot lifecycle derived from the associated policy (Agarwal: 8:1-20), such as creation time. Agarwal stores these records in addition to the corresponding snapshots (Agarwal: fig. 1b, #124 & #126).
Retrieving the first snapshot from the selected archive location.
Agarwal teaches “In the event that data contained on a storage volume may need to be restored, active storage snapshots associated with the storage volume may contain information needed to restore the data to a new storage volume.” (Col. 1 Lines 29-33).
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Agarwal and Ashutosh at the time that the claimed invention was effectively filed, to have modified the systems and methods for managing data in accordance with service level agreements (SLAs), as taught by Ashutosh with the storage snapshot policy, as taught by Agarwal.
One would have been motivated to make such combination because one having ordinary skill in the art would have found motivation to tag snapshots of Ashutosh with the storage snapshot policy of Agarwal, including parameters on how often and how long to create and maintain snapshots, to effectively perform snapshot scheduling.
Agarwal and Ashutosh explicitly teach all of the elements of the claimed invention as recited above except:
Providing, via a user interface of a computing system and in response to receiving a request to restore the computing object using the first snapshot, a listing of the one or more respective identified archive locations that includes the first respective archive location and the second respective archive location;
Receiving, via the user interface of the computing system and after providing the listing, a selection of either the first respective archive location or the second respective archive location; and
Retrieving the first snapshot from the selected archive location in response to the selection of either the first respective archive location or the second respective archive location.
However, in the related field of endeavor of generating and storing backups or secondary copies, Iyer teaches:
Providing, via a user interface of a computing system and in response to receiving a request to restore the computing object using the first snapshot, a listing of the one or more respective identified archive locations that includes the first respective archive location and the second respective archive location;
Iyer teaches “pull-down menus or entries allowing one or more of several options to be selected, buttons, sliders, hypertext links or other known user interface tools for receiving user input, etc.” (Para. [0244]) and “a user may manually initiate a restore of backup copy 116A, e.g., by interacting with user interface 158 of storage manager 140 or with a web-based console with access to system 100. Storage manager 140 may accesses data in its index 150 and/or management database 146 (and/or the respective storage policy 148A) associated with the selected backup copy 116A to identify the appropriate media agent 144A and/or secondary storage device 108A where the secondary copy resides. The user may be presented with a representation (e.g., stub, thumbnail, listing, etc.) and metadata about the selected secondary copy, in order to determine whether this is the appropriate copy to be restored” (Para. [0246])
Iyer further teaches providing a user interface where a user “may select the SQL client that includes the backup snapshot copies, and request a browse and restore operation 535 of the application-specific data” (Para. [0300]) where “the interface 550 depicts the database expanding to show its contents. For example, interface 550 depicts a listing of all databases 555 associated with a Sharepoint operation of the virtual machine.” (Para. [0301])
Receiving, via the user interface of the computing system and after providing the listing, a selection of either the first respective archive location or the second respective archive location; and
Iyer teaches “pull-down menus or entries allowing one or more of several options to be selected, buttons, sliders, hypertext links or other known user interface tools for receiving user input, etc.” (Para. [0244]) and “a user may manually initiate a restore of backup copy 116A, e.g., by interacting with user interface 158 of storage manager 140 or with a web-based console with access to system 100. Storage manager 140 may accesses data in its index 150 and/or management database 146 (and/or the respective storage policy 148A) associated with the selected backup copy 116A to identify the appropriate media agent 144A and/or secondary storage device 108A where the secondary copy resides. The user may be presented with a representation (e.g., stub, thumbnail, listing, etc.) and metadata about the selected secondary copy, in order to determine whether this is the appropriate copy to be restored” (Para. [0246])
Iyer further teaches providing a user interface where a user “may select the SQL client that includes the backup snapshot copies, and request a browse and restore operation 535 of the application-specific data” (Para. [0300]) where “the interface 550 depicts the database expanding to show its contents. For example, interface 550 depicts a listing of all databases 555 associated with a Sharepoint operation of the virtual machine.” (Para. [0301])
Retrieving the first snapshot from the selected archive location in response to the selection of either the first respective archive location or the second respective archive location.
Iyer teaches “pull-down menus or entries allowing one or more of several options to be selected, buttons, sliders, hypertext links or other known user interface tools for receiving user input, etc.” (Para. [0244]) and “a user may manually initiate a restore of backup copy 116A, e.g., by interacting with user interface 158 of storage manager 140 or with a web-based console with access to system 100. Storage manager 140 may accesses data in its index 150 and/or management database 146 (and/or the respective storage policy 148A) associated with the selected backup copy 116A to identify the appropriate media agent 144A and/or secondary storage device 108A where the secondary copy resides. The user may be presented with a representation (e.g., stub, thumbnail, listing, etc.) and metadata about the selected secondary copy, in order to determine whether this is the appropriate copy to be restored” (Para. [0246])
Iyer further teaches providing a user interface where a user “may select the SQL client that includes the backup snapshot copies, and request a browse and restore operation 535 of the application-specific data” (Para. [0300]) where “the interface 550 depicts the database expanding to show its contents. For example, interface 550 depicts a listing of all databases 555 associated with a Sharepoint operation of the virtual machine.” (Para. [0301])
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Iyer, Agarwal, and Ashutosh at the time that the claimed invention was effectively filed, to have modified the systems and methods for managing data in accordance with service level agreements (SLAs), as taught by Ashutosh, and the storage snapshot policy, as taught by Agarwal, with the interface for selecting copies and data for restoration operations, as taught by Iyer.
One would have been motivated to make such combination because Iyer teaches “The user interfaces described herein may provide improved human-computer interactions, allowing for significant cognitive and ergonomic efficiencies and advantages over previous systems, including reduced mental workloads, improved decision-making, and the like.” (Para. [0111]).
Regarding Claim 2:
Iyer, Agarwal, and Ashutosh further teach:
Claim 2 recites “The method of claim 1, wherein obtaining the snapshots of the computing object comprises: generating, by the data management system, a backup job for the computing object; and capturing, via the backup job, the snapshots of the computing object based at least in part on a service level agreement for the computing object, the service level agreement comprising a snapshot frequency policy and an archival policy, wherein the snapshots are obtained based at least in part on the snapshot frequency policy.”
Ashutosh manages data according to SLAs that specify schedules for performing (i.e., generating) a snapshot function (i.e., backup job). Each SLA specifies a service level policy (i.e., archival policy) identifying parameters such as source and destination pools, a copy frequency (i.e., snapshot frequency policy), retention period, and schedule information for managing (i.e., capturing) snapshots [0037].
Regarding Claim 3:
Iyer, Agarwal, and Ashutosh further teach:
Claim 3 recites “The method of claim 2, further comprising: receiving, at the data management system, an indication of the service level agreement.”
Each SLA of Ashutosh specifies a service level policy identifying (i.e., indicating) parameters such as source and destination pools, a copy frequency, retention period, and schedule information for managing snapshots [0037].
Regarding Claim 4:
Iyer, Agarwal, and Ashutosh further teach:
Claim 4 recites “The method of claim 2, further comprising: wherein tagging the snapshots with the one or more respective frequency parameters is based at least in part on the snapshot frequency policy.”
Each SLA of Ashutosh specifies a service level policy identifying parameters such as source and destination pools, a copy frequency (i.e., snapshot frequency policy), retention period, and schedule information for managing snapshots [0037].
Ashutosh and Agarwal teach claim 2, where Agarwal tags a computing instance and its assigned storage volume with the applicable storage snapshot policy (Agarwal: 2:25-33), including parameters such as frequency for how often a snapshot is created from the storage volume, snapshot time, and retention period (Agarwal: fig. 1a; 3:37-48).
Regarding Claim 5:
Iyer, Agarwal, and Ashutosh further teach:
Claim 5 recites “The method of claim 4, wherein tagging the first snapshot of the snapshots with both the first archival policy parameter and the second archival policy parameter is based at least in part on the archival policy, wherein the first archival policy parameter is associated with the first respective archive location of the set of two or more candidate archive locations and the second archival policy parameter is associated with the second respective archive location of the set of two or more candidate archive locations.”
Ashutosh deploys the snapshot store to one or more hosts [0057]. Each SLA specifies a service level policy (i.e., archival policy) identifying parameters such as source and destination pools (i.e., first/second archive locations), a copy frequency, retention period, and schedule information for managing snapshots [0037]. Ashutosh improves storage capacity and network bandwidth by tracking portions of data that have changed over time, and by data deduplication and compression to reduce the amount of data to be copied and moved [0040], such as to avoid sending data that is already available at the destination [0043]. Repeated copying is reduced with a single copy (i.e., first snapshot) sent to two destinations serving two purposes, one being the remote storage for archive, and the other being the private cloud for disaster recovery [0050].
Ashutosh and Agarwal teach claim 4, where Agarwal tags a computing instance and its assigned storage volume with the applicable storage snapshot policy (Agarwal: 2:25-33), including parameters such as frequency for how often a snapshot is created from the storage volume, snapshot time, and retention period (Agarwal: fig. 1a; 3:37-48).
Regarding Claim 7:
Iyer, Agarwal, and Ashutosh further teach:
Claim 7 recites “The method of claim 1, wherein identifying the one or more respective archive locations comprises: generating, by the data management system based at least in part on the archival job periodicity parameter, an archival job for the one or more storage nodes; and determining, by the archival job, for the snapshots stored in the one or more storage nodes, the one or more respective archive locations based at least in part on the tagged one or more respective frequency parameters and the tagged one or more respective archival policy parameters of the snapshots stored in the one or more storage nodes.”
Ashutosh deploys the snapshot store to one or more hosts (i.e., storage nodes) [0057]. Each SLA specifies a service level policy (i.e., archival policy) identifying parameters such as source and destination pools, a copy frequency (i.e., periodicity parameter), retention period, and schedule information for managing snapshots [0037]. A service level policy engine acts on the SLA to make decisions regarding the creation, movement and deletion of snapshot copies of data. The engine analyzes each SLA to derive (i.e., generate) a series of actions (i.e., archival job) each of which involves copying data from one storage location to another (i.e., archive locations) [0061].
Ashutosh and Agarwal teach claim 1, where Agarwal tags a computing instance and its assigned storage volume with the applicable storage snapshot policy (Agarwal: 2:25-33), including parameters such as frequency for how often a snapshot is created from the storage volume, snapshot time, and retention period (Agarwal: fig. 1a; 3:37-48).
Regarding Claim 8:
Iyer, Agarwal, and Ashutosh further teach:
Claim 8 recites “The method of claim 1, further comprising: generating, by the data management system based on a periodicity parameter, an expiration job for the computing object; identifying, by the expiration job based at least in part on the tagged one or more respective frequency parameters, that one or more snapshots of the snapshots transmitted to the one or more respective identified archive locations are expired; and transmitting an indication to the one or more respective identified archive locations that the one or more snapshots are expired.”
An SLA of Ashutosh specifies a service level policy identifying parameters such as source and destination pools, a copy frequency (i.e., periodicity parameter), retention period, and schedule information for managing snapshots [0037]. When the policy manager determines that a snapshot's retention period has expired, Ashutosh invokes (i.e., transmits) a "Remove" operation (i.e., expiration job) to make the snapshot inaccessible (i.e., indication), which is later automatically deleted from the system (i.e., archive locations) by a garbage collection process [0212].
Ashutosh and Agarwal teach claim 1, where Agarwal tags a computing instance and its assigned storage volume with the applicable storage snapshot policy (Agarwal: 2:25-33), including parameters such as frequency for how often a snapshot is created from the storage volume, snapshot time, and retention period (Agarwal: fig. 1a; 3:37-48).
Regarding Claim 9:
Iyer, Agarwal, and Ashutosh further teach:
Claim 9 recites “The method of claim 1, further comprising: generating, by the data management system based on a periodicity parameter, an expiration job for the computing object; and removing, by the expiration job, one or more snapshots from the one or more storage nodes after transmitting the snapshots to the one or more respective identified archive locations in accordance with respective archival policy parameters of the one or more snapshots.”
Ashutosh deploys the snapshot store to one or more hosts (i.e., storage nodes) [0057]. Each SLA specifies a service level policy (i.e., archival policy) identifying parameters such as source and destination pools, a copy frequency (i.e., periodicity parameter), retention period, and schedule information for managing snapshots [0037]. When the policy manager determines that a snapshot's retention period has expired, Ashutosh invokes (i.e., generates) a "Remove" operation (i.e., expiration job) to make the snapshot inaccessible, which is later automatically deleted from the system (i.e., archive locations) by a garbage collection process [0212].
Regarding Claim 10:
Iyer, Agarwal, and Ashutosh further teach:
Claim 10 recites “The method of claim 1, further comprising: receiving a request to retrieve a second snapshot of the snapshots for the computing object, wherein the second snapshot is stored in two or more archive locations from among the set of two or more candidate archive locations, the request indicating a recovery purpose for the second snapshot; and retrieving the first snapshot from a first archive location of the two or more archive locations in response to the request to retrieve, the first archive location identified based at least in part on the indicated recovery purpose.”
Ashutosh provides protocol operations (i.e., requests) for creation, destruction, duplication, copying, and maintaining access of snapshot copies of data [0069] to meet user-provided SLAs [0075]. For example, data (i.e., second snapshot) may be backed up in a performance-optimized pool (i.e., second archive location) for rapid access during disaster recovery [0083], and also in a capacity-optimized pool (i.e., first archive location) for data retention [0084]. To meet performance SLA for restore operations (i.e., recovery purpose), the snapshot in the performance-optimized pool (i.e., second snapshot) is retrieved.
Regarding Claim 11:
Iyer, Agarwal, and Ashutosh further teach:
Claim 11 recites “The method of claim 1, further comprising: receiving a request to restore the computing object using a second snapshot of the snapshots; providing a listing of the one or more respective identified archive locations for the second snapshot in response to the request to restore; receiving, after providing the listing, a selection of a first archive location of the one or more respective identified archive locations for the second snapshot; and retrieving the second snapshot from the first archive location in response to the selection of the first archive location.”
Ashutosh provides protocol operations (i.e., requests) for creation, destruction, duplication, copying, and maintaining access (i.e., restore) of snapshot copies of data [0069] to meet user-provided SLAs [0075]. For example, data (i.e., second snapshot) may be backed up in two storage pools displayed (i.e., provided listing) via a user interface [0163]: a performance-optimized pool (i.e., second archive location) for rapid access during disaster recovery [0083], and also in a capacity-optimized pool (i.e., first archive location) for data retention [0084]. To meet performance SLA for restore operations, the snapshot in the performance-optimized pool (i.e., second snapshot) is retrieved (i.e., selected).
Regarding Claim 12:
Iyer, Agarwal, and Ashutosh further teach:
Claim 12 recites “The method of claim 1, wherein: the first respective archive location of the set of two or more candidate archive locations comprises a first storage environment associated with the long-term retention parameter, and the second respective archive location of the set of two or more candidate archive locations comprises a second storage environment associated with the disaster recovery parameter.”
Ashutosh virtualizes physical storage resources for the snapshot store, including local/primary and remote/secondary storage devices and public/private/hybrid storage clouds, into data protection storage pools that are independent of the type, physical location or underlying storage technology, such as a Quick Recovery Pool (i.e., disaster recovery parameter), a Cost Efficient Long-term Storage Pool (i.e., long-term retention parameter), or a tape library [0042]. Data may be backed up in a performance-optimized pool (i.e., second storage environment) for rapid access during disaster recovery [0083], and also in a capacity-optimized pool (i.e., first storage environment) using deduplication techniques [0084].
Regarding Claim 13:
Iyer, Agarwal, and Ashutosh further teach:
Claim 13 recites “The method of claim 1, further comprising: detecting, by a second data management system, an unavailability of the data management system; identifying, by the second data management system, the one or more respective identified archive locations for the snapshots based at least in part on the unavailability of the data management system; and retrieving, by the second data management system, the snapshots from the one or more respective identified archive locations.”
A data management virtualization engine in Ashutosh manages lifecycle of application data as specified in SLAs [0055]. The engine runs as multiple processes (i.e., first and second data management systems) on a fault tolerant, redundant pair of computers (i.e., archive locations) [0058], working in near-lockstep to switch (i.e., detect) incoming requests away from a failed (i.e., unavailable) server to its peer [0016].
Regarding Claim 14:
Some of the limitations herein are similar to some or all of the limitations as recited in Claim 1.
Iyer, Agarwal, and Ashutosh further teach an apparatus, comprising:
At least one processor (Ashutosh – Para. [0251]);
Memory coupled with the at least one processor (Ashutosh – Para. [0251]); and
Instructions stored in the memory and executable by the at least one processor to cause the apparatus to perform steps (Ashutosh – Para. [0251]).
Regarding Claim 15:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 2.
Regarding Claim 17:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 4.
Regarding Claim 18:
All of the limitations herein are similar to some or all of the limitations as recited in Claim 5.
Regarding Claim 20:
Some of the limitations herein are similar to some or all of the limitations as recited in Claim 1.
Iyer, Agarwal, and Ashutosh further teach an apparatus, comprising:
A non-transitory computer-readable medium storing code, the code comprising instructions executable by at least one processor to perform steps (Ashutosh – Paras. [0042] and [0251]).
Regarding Claim 21:
Iyer, Agarwal, and Ashutosh further teach:
Claim 21 recites “The method of claim 1, wherein the one or more respective archive locations are identified by the data management system for the snapshots stored in the one or more storage nodes in chronological order from an oldest snapshot of the snapshots to a newest snapshot of the snapshots.”
Ashutosh virtualizes (i.e., identifies) physical storage resources for the snapshot store, including local and remote storage devices (i.e., storage nodes) and public/private/hybrid storage clouds (i.e., archive locations), into data protection storage pools that are independent of the type, physical location or underlying storage technology, such as a Quick Recovery Pool, a Cost Efficient Long-term Storage Pool, or a tape library [0042]. Each storage pool is characterized by geographic location, speed and cost attributes [0063]. Ashutosh records historical information about previous snapshots , including timestamp, order (i.e., chronological order), and hierarchy [0176].
Regarding Claim 22:
Iyer, Agarwal, and Ashutosh further teach:
Claim 22 recites “The method of claim 1, further comprising: identifying, at a first time by the data management system, an absence of a tagged frequency parameter for a snapshot stored in the one or more storage nodes; and skipping, at the first time, identifying of a respective one or more archive locations from among the set of two or more candidate archive locations for the snapshot based at least in part on the identified absence of the tagged frequency parameter for the snapshot.”
Ashutosh deploys the snapshot store to one or more hosts (i.e., storage nodes) [0057]. Each SLA specifies a service level policy identifying parameters such as source and destination pools (i.e., archive locations), a copy frequency, retention period, and schedule information [0037]. Ashutosh continuously cycles through all SLAs, discards (i.e., skips) those policies that are not applicable (i.e., policy absence) [0183], and rules out making a new copy if any of a series of checks is satisfied [0184].
Ashutosh and Agarwal teach claim 1, where Agarwal tags a computing instance and its assigned storage volume with the applicable storage snapshot policy (Agarwal: 2:25-33), including parameters such as frequency for how often a snapshot is created from the storage volume, snapshot time, and retention period (Agarwal: fig. 1a; 3:37-48).
Regarding Claim 23:
Iyer, Agarwal, and Ashutosh further teach:
Claim 23 recites “The method of claim 22, further comprising: tagging, by the data management system at a second time subsequent to the first time, the snapshot with a frequency parameter; identifying, by the data management system at a third time subsequent to the second time, the respective one or more archive locations from among the set of two or more candidate archive locations for the snapshot based at least in part on the tagged frequency parameter a tagged archival policy parameter; and transmitting the snapshot from the one or more storage nodes to the identified respective one or more archive locations.”
Ashutosh deploys the snapshot store to one or more hosts (i.e., storage nodes) [0057]. Each SLA specifies a service level policy identifying parameters such as source and destination pools (i.e., archive locations), a copy frequency, retention period, and schedule information [0037]. Ashutosh continuously cycles through all SLAs, and finds a policy with the shortest frequency and the longest retention that needs to be run next [0183]. A new copy is made if none of a series of checks apply [0184].
Ashutosh and Agarwal teach claim 22, where Agarwal tags a computing instance and its assigned storage volume with the applicable storage snapshot policy (Agarwal: 2:25-33), including parameters such as frequency for how often a snapshot is created from the storage volume, snapshot time, and retention period (Agarwal: fig. 1a; 3:37-48).
Response to Amendment
Applicant’s Amendments, filed on 2/27/2026, are acknowledged and accepted.
Response to Arguments
On pages 13-15 of the Remarks filed on 2/27/2026, Applicant argues that “Ashutosh and Agarwal-alone or in any combination-do not teach or suggest all of the features of amended independent claims 1, 14, and 20” because “Ashutosh discusses a user creating a service level agreement through a user interface, and the service level agreement being used to determine which storage pool to use to store copies of data.” and “a user creating a service level agreement through a user interface, as described by Ashutosh, does not teach or suggest "providing, via a user interface of a computing system and in response to receiving a request to restore the computing object using the first snapshot, a listing of the one or more respective identified archive locations that includes the first respective archive location and the second respective archive location," as recited in amended independent claim 1” and that “Agarwal does not overcome the deficiencies of Ashutosh, nor does the Office Action suggest otherwise.”.Applicant’s argument is convincing that Ashutosh and Agarwal, either alone or in combination, do not teach all of the features of the amended claims, thus requiring the new grounds of rejection presented herein. The amended claims have been addressed in full above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pandey et al. (U.S. Pre-Grant Publication No. 2019/0227877) teachesefficiently downloading archived snapshot data from the cloud or from an archival data store are described. In a disaster recovery scenario in which an entire storage appliance for backing up different point in time versions of a virtual machine has failed (e.g., due to a fire), archived snapshot data for the different point in time versions may be acquired by a second storage appliance from an archival data store (e.g., cloud-based data storage) using one or more snapshot mapping files. A snapshot mapping file may include pointers to a plurality of data blocks within the archival data store for generating a full image snapshot associated with a particular point in time version of the virtual machine. The plurality of data blocks may comprise the minimum number of data blocks necessary to construct the particular point in time version of the virtual machine.The reference further teaches “The particular version of the file may be selected by an end user of a storage appliance, such as storage appliance 170 in FIG. 1A, using a user interface provided by the storage appliance. In step 371, a virtual machine search index, such as virtual machine search index 106 in FIG. 1C, for the virtual machine is acquired. In step 372, a version of the virtual machine that includes the particular version of the file is identified using the virtual machine search index.” (Para. [0110]).
Thompson et al. (U.S. Pre-Grant Publication No. 2007/0006017) teaches backing up and/or restoring data. When a backup operation is initiated, systems and methods are provided for creating a single snapshot of the backup items, including backup groupings. The single snapshot is used by a backup/recovery application to perform a save process on each backup grouping. By using the same snapshot, the backup is performed based on the same point in time so that the backed up data across the client system is consistent and synchronized. When a recovery operation is initiated, recovery items (e.g., backup groupings, writers and writer components) are selected from backup groupings of the client.The reference further teaches “Typically, a user will choose to select all of the backup groupings relating to the volumes of a client or computer to be backed up. In this case, the single snapshot captures a representation of all the data of the volumes of a client or computer at a single point in time, allowing, for example, the operating system state to also be consistent with a single point in time. However, less than all of the backup groupings may be selected by the user which specifies that less than all of the data of a client should be backed up. This may be beneficial where the user knows that changes have occurred only in certain backup groupings without performing a backup of the entire client data system. A user may select one or more backup groupings by accessing a user interface that communicates with a backup/restore application. Backup groupings may include information that identifies the items that need to be backed up. Because the items identified in a backup grouping may be distributed among multiple volumes, embodiments of the invention can ensure that the corresponding volumes are included in the single snapshot and that the corresponding data is properly backed up, as will be discussed further below.” (Para. [0027])
Awasthi et al. (U.S. Pre-Grant Publication No. 2016/0292074) teaches creating snapshots and backups in a virtual computing environment is provided. The method includes writing application output of an application spanning one or more virtual machines as an application consistency group to a writeback cache, wherein the one or more virtual machines are implemented using one or more compute nodes and wherein the writeback cache is implemented in direct attached storage in the one or more compute nodes. The method includes pausing I/O (input/output) operations of the application and marking the pausing, in the writeback cache. The method includes resuming the I/O operations of the application, after the marking and dumping data, according to the marking, from the writeback cache to a data node, as a snapshot.The reference further teaches “an example user interface screen 406 showing a timeline 402 with snapshots 314 and a backup 316, with various options for restoring. Restoring occurs from the data plane to the compute plane. Some embodiments of the user screen 406 show virtual disks 128, and allow selection of a virtual disk 128, virtual machines 116 with selection of a virtual machine 116, or application consistency group 304, with selection of an application consistency group 304. Snapshots 314 and backups 316 are displayed accordingly. The options are shown as soft buttons 404, but could also be implemented as drop-down menus, icons or in other formats as readily devised. One soft button 404 allows the user to “select time point for restore”, inviting the user to select one of the snapshots 314 or backups 316 shown on the timeline 402. Two more soft buttons 404 allow the user to “restore to original virtual machine” or “restore to new virtual machine”. Pressing either of these soft buttons 404 could bring up lists or diagrams or other representations of existing or new virtual machines 116. After selecting a snapshot 314 or a backup 316, and selecting whether to restore to an original virtual machine or a new virtual machine, the user could click on the “initiate restore” soft button 404. In some embodiments the snapshots 314 and backups 316 are represented on the user interface screen 406 in undifferentiated form, so that it is transparent to the user whether a time point is associated with a snapshot 314 or a backup 316. Further embodiments of the user interface screen 406 are readily devised in accordance with the teachings herein.” (Para. [0029]).
Patterson et al. (U.S. Patent No. 10,866,742) teaches archiving storage volume snapshots. An archive module determines at least one snapshot or point in time copy of data. A metadata module determines metadata for restoring a snapshot or point in time copy. A storage module replicates a snapshot or point in time copy and stores the replicated snapshot or point in time copy and metadata to a target storage location, such as one or more data files in a file system of one or more storage devices from a different vendor than a storage device from which the data was copied. In another embodiment, both the ability to archive a storage volume snapshot and restore a previously archived storage volume snapshot is provided.The reference further teaches “The selection module 302 may identify archived storage volume snapshot data for retrieval or restoration from a storage location based on user input (e.g., a user selection of archived storage volume snapshot data for retrieval using a graphical user interface, a command line interface, or another user interface); based on an archival-restoration policy, an archival-restoration rule, and/or an archival-restoration plan; based on a quality-of-service level for data of archived snapshot data; based on a time or time period in which a snapshot was made; and/or based on another attribute of a snapshot, of data of a snapshot, or the like.” (Col. 21 Lines 18-42)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT F MAY whose telephone number is (571)272-3195. The examiner can normally be reached Monday-Friday 9:30am to 6pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Boris Gorney can be reached on 571-270-5626. 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.
/ROBERT F MAY/Examiner, Art Unit 2154 6/13/2026
/SYED H HASAN/Primary Examiner, Art Unit 2154
Prosecution Insights