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
1. This action is responsive to the communication filed on 9/16/26. Claim 1 has been amended. Claims 5-7 have been cancelled. Claims 1-4 are pending.
2. Applicants' arguments filed 9/16/26 have been fully considered but they are not deemed to be persuasive. Rejections and/or objections not reiterated from previous office actions are hereby withdrawn. The following rejections and/or objections are either reiterated or newly applied. They constitute the complete set presently being applied to the instant application.
Claim Rejections - 35 USC § 101
3. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
4. Claims 1-4 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis below of the claims’ subject matter eligibility follows the guidance set forth in MPEP 2106 which has incorporated the 2019 PEG.
Regarding to claim 1,
Step 1 Analysis: Claim 1 is directed to a system, which is directed to a machine, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 1 recites: A storage system comprising:
“each of the storage nodes includes a volume and a plurality of snapshot volumes that are snapshots of the volume”. This element reads on a person includes a volume and a plurality of snapshot volumes that are snapshots of the volume which could be considered a mental process of an observation or evaluation.
“wherein, upon migrating the volume and the plurality of snapshot volumes from a migration source storage node to a migration destination storage node”. This element reads on a person migrates the volume and the plurality of snapshot volumes from a migration source storage node to a migration destination storage node which could be considered a mental process of an observation or evaluation.
“the migration source storage node transfers data of the volume to the migration destination storage node”. This element reads on a person transfers data of the volume to the migration destination storage node which could be considered a mental process of an observation or evaluation.
“compares a sum of difference amounts of parent-child difference data indicating differences between the volume as a migration target and the plurality of snapshot volumes with a sum of difference amounts of inter-generation difference data indicating inter-generation differences between the plurality of snapshot volumes”. This element reads on a person compares a sum of difference amounts of parent-child difference data indicating differences between the volume as a migration target and the plurality of snapshot volumes with a sum of difference amounts of inter-generation difference data indicating inter-generation differences between the plurality of snapshot volumes which could be considered a mental process of an observation or evaluation.
“for each feature in the input multidimensional data element:
determining a feature bucket for a value of the feature of the input multidimensional data element”. This element reads on a person determines a feature range for a value of the data element which could be considered a mental process of an observation or evaluation.
“transfers the parent-child difference data to the migration destination storage node upon determining the difference amount of the parent-child difference data is smaller than the difference amount of the inter-generation difference data, and transfers the inter-generation difference data to the migration destination storage node upon determining the difference amount of the inter-generation difference data is smaller than the difference amount of the parent-child difference data”. This element reads on a person transfers the parent-child difference data to the migration destination storage node upon determining the difference amount of the parent-child difference data is smaller than the difference amount of the inter-generation difference data, and transfers the inter-generation difference data to the migration destination storage node upon determining the difference amount of the inter-generation difference data is smaller than the difference amount of the parent-child difference data which could be considered a mental process of an observation or evaluation.
“the migration destination storage node uses the received data of the volume and the received inter-generation difference data or the received parent-child difference data to associate the volume and the plurality of snapshot volumes with the migration destination storage node”. This element reads on a person uses the received data of the volume and the received inter-generation difference data or the received parent-child difference data to associate the volume and the plurality of snapshot volumes with the migration destination storage node which could be considered a mental process of an observation or evaluation.
Overall, the limitations directed to migrate data and the various mental process limitations in the context of this claim encompasses limitations that are not only considered to be directed to limitations that could be practically performed in the human mind (including observations and preform an evaluation, judgment, and opinion) aided by the use of pen and paper. If the claim limitations, under their broadest reasonable interpretations, cover performance of the limitation in the mind but for the recitation of generic computer components, then they fall within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: In Step 2A Prong 2, we are directed to Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception.
In particular, the claim only recites the additional elements of “a plurality of storage nodes each having a processor”
Regarding the plurality of storage nodes each having a processor,
The processor of a computer system for generating and storing in all steps is recited at a high level of generality, i.e., as a generic processor performing a generic computer function of processing data (generating and storing). This generic processor limitation is no more than mere instructions to apply the exception using a generic computer component(s). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
The additional element “a plurality of storage nodes each having a processor” is simply applying the abstract idea, and there is nothing done with results. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea, and does not provide any improvement in computer technology (see MPEP2106.05(a)).
Therefore, the additional elements do not integrate the judicial exception into a practical application.
Step 2B Analysis: In Step 2B, we are directed to Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether the additional elements, taken individually and in combination, result in the claim as a whole amounting to significantly more than the judicial exception.
As discussed above with respect to integration of the abstract idea into a practical application, The additional elements “a plurality of storage nodes each having a processor” is simply applying the abstract idea, and there is nothing done with results.
Accordingly, this additional element(s), taken individually and in combination, do not result in the claim as a whole amounting to significantly more than the judicial exception. The claim is not patent eligible.
Regarding claim 2,
Step 1 Analysis: Claim 2 is directed to a system, which is directed to a machine, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 2 is dependent on claim 1, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 2 recites “each of the snapshot volumes is created by duplicating the volume, and data is writable into the snapshot volume after creation." That is, the claim recites each of the snapshot volumes is created by duplicating the volume, and data is writable into the snapshot volume after creation. The above-noted limitation of claim 2, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Regarding claim 3,
Step 1 Analysis: Claim 3 is directed to a system, which is directed to a machine, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 3 is dependent on claims 1&2, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 3 recites “the migration source storage node compares the volume with the plurality of snapshot volumes, extracts the parent-child difference data and the inter-generation difference data, and determines the parent-child difference data or the inter-generation difference data to be transferred to the migration destination storage node." That is, the claim recites the migration source storage node compares the volume with the plurality of snapshot volumes, extracts the parent-child difference data and the inter-generation difference data, and determines the parent-child difference data or the inter-generation difference data to be transferred to the migration destination storage node. The above-noted limitation of claim 3, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Regarding claim 4,
Step 1 Analysis: Claim 4 is directed to a system, which is directed to a machine, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 4 is dependent on claim 1, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 4 recites “
the migration source storage node transfers the inter-generation difference data, and
the migration destination storage node copies a snapshot image between generations of the snapshot volume of the migration destination storage node
" That is, the claim recites
the migration source storage node transfers the inter-generation difference data, and
the migration destination storage node copies a snapshot image between generations of the snapshot volume of the migration destination storage node. The above-noted limitation of claim 4, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Claim Rejections - 35 USC § 103
5. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
6. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
7. 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.
8. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
9. Claims 1-4 are rejected under 35 U.S.C. 103 as being unpatentable over Nagapudi in view of Dayal et al (U.S. Patent 10628378 B2 hereinafter, “Dayal”).
10. With respect to claim 1,
Nagapudi discloses A storage system comprising:
a plurality of storage nodes each having a processor,
wherein
each of the storage nodes (e.g. servers) includes a volume (e.g. volume) and a plurality of snapshot volumes (e.g. snapshots) that are snapshots of the volume,
wherein, upon migrating (Nagapudi col. 10 lines 1-54 e.g. migration; restore) the volume and the plurality of snapshot volumes from a migration source storage node (e.g. source server) to a migration destination storage node (e.g. target server),
the migration source storage node
transfers data of the volume to the migration destination storage node (e.g. source snapshot volume to target snapshot volume),
compares (e.g. comparison; comparing; compare - compare the manifests for two snapshots and identify differences based on the different objects in each manifest (where a given different object indicates that the one or more blocks stored in that object are different between the two snapshots)) a sum (e.g. The difference between a snapshot and a "sibling" (e.g., two distinct snapshots each created from a common parent) can be represented as the sum of deltas between the parent and each child) of difference amounts (e.g. differences) of parent-child difference (e.g. parent-child) data indicating differences between the volume (e.g. volume) as a migration (e.g. migration; restore) target (e.g. target server) and the plurality of snapshot volumes (e.g. snapshot … volumes) with a sum (e.g. the difference between a child and a more distance direct predecessor snapshot (e.g., a "grandparent" or "great grandparent") can be represented as the sum of deltas between each generation … combine differences for each generationally link in a lineage tree between the two snapshots, in order to determine total differences between two snapshots) of difference amounts of inter-generation (e.g. between each generation … each generationally link in a lineage tree between the two snapshots) difference data indicating inter-generation differences between the plurality of snapshot volumes, and
transfers (e.g. transfer) the parent-child difference data (e.g. parent-child) to the migration (e.g. migration; restore) destination storage node upon determining the difference amount of the parent-child difference data is the difference amount of the inter-generation difference data (e.g. between each generation … each generationally link in a lineage tree between the two snapshots), and transfers (e.g. transfer) the inter-generation difference data to the migration destination storage node upon determining the difference amount of the inter-generation difference data is the difference amount (e.g. differences) of the parent-child difference data (e.g. parent-child), and
the migration destination storage node uses the received data of the volume and the received inter-generation difference data or the received parent-child difference data to associate the volume and the plurality of snapshot volumes with the migration destination storage node (Nagapudi Abstract, col. 4 line 42 – col. 5 line 32, col. 12 line 46 – col. 13 line 21, col. 14 lines 12-36 e.g. [abstract] Systems and methods are provided for conducting incremental restore operations on block storage volumes using an object-based snapshot. A full restore from an object-based snapshot can include copying all blocks of a data set from the object-based snapshot to a destination volume. …. Embodiments of the present disclosure provide for incremental restore operations, where a delta data set is transferred from the snapshot to the destination volume, representing data in the snapshot is not known to already exist on the volume or another available volume. (14) In addition to knowledge that an existing volume stores data corresponding to another snapshot, incremental restore can be based at least partly on knowledge of a delta between two snapshots. For example, a snapshot service can maintain snapshots within a hierarchical structure, with a root snapshot indicating a first known set of block values, and each "child" snapshot representing a difference in block values relative to a parent snapshot. In one embodiment, creation of a child snapshot may be incremental, such that only blocks of a volume that have changed since the prior "parent" snapshot are written to the service. These changed blocks then reflect the delta between the two snapshots. This process can be repeated to identify the delta (e.g., those blocks with different data) for any two snapshots within the hierarchy. For example, the difference between a child and a more distance direct predecessor snapshot (e.g., a "grandparent" or "great grandparent") can be represented as the sum of deltas between each generation. The difference between a snapshot and a "sibling" (e.g., two distinct snapshots each created from a common parent) can be represented as the sum of deltas between the parent and each child. …. Accordingly, deltas between any two related snapshots can be quickly identified within a snapshot hierarchy. Notably, these techniques do not require direct comparison of data within two snapshots, as the delta from a prior snapshot can be record when creating that snapshot. …. (15) In some embodiments, a snapshot service may further identify differences between unrelated snapshots. For example, the service may enable a block-by-block comparison of the two snapshots, to identify such differences. In some cases, block-by-block comparisons can be made more efficient based on storage of blocks. For example, a snapshot service may store blocks in objects (e.g., files). In some instances, each object may reflect a single block of a volume. In other instances, each object may reflect multiple blocks. …. The service may then identify identical object when their object identifiers match, and identify non-identical object when such identifiers do not match. By comparing the identifiers of all object within two snapshots, differences between the snapshots can be quickly identified. For example, a snapshot service may store for each snapshot a "manifest" that lists all objects making up the snapshot. The differences between two snapshots may then be determined by identifying all objects listed in the manifest for one snapshot but not in the manifest for the other (43) At block (3), the block store server 105 requests from the object storage server 110 a listing of block differences between the source and target snapshot. The server 110 then, at (4), identifies those differences. As noted above, the object storage server 110 may identify differences based on a variety of techniques. For example, the server 110 may maintain, for each snapshot, a manifest indicating objects of the snapshot. The server 110 may thus compare the manifests for two snapshots and identify differences based on the different objects in each manifest (where a given different object indicates that the one or more blocks stored in that object are different between the two snapshots). Where two snapshots are related in lineage (e.g., as part of the same lineage tree), the server 110 may identify different based on the relationship between the two snapshots. For example, the server 110 may maintain information identifying differences between a parent and child snapshot, and may combine differences for each generationally link in a lineage tree between the two snapshots, in order to determine total differences between two snapshots. On identifying the differences, the server 110 returns a listing of the differences at (5). The listing may include for example a listing of blocks (e.g., as identifiers, such as block 1, block 2, etc.), a listing of objects in the snapshot that contain altered blocks, or both. (38) To facilitate updating read only recovery volumes 106B based on snapshots, the block storage services 105 can support incremental snapshot restore operations, in which a snapshot restore operation can be completed based on retrieval of only a delta between a target snapshot (being restored) and a source snapshot for a source volume (e.g., a read only recovery volume 106B). The object storage services 110 can illustratively maintain information used to identify that delta. For example, the services 110 may store snapshot metadata 214 indicating relationships between various snapshots, such as organized into a hierarchy (e.g., a tree data structure) that associates snapshots by lineage from a root snapshot. As discussed above, each snapshot may be stored as a set of objects 202 within block storage buckets 111, along with a manifest 204 for the snapshot that lists objects of the snapshot. By comparing the manifests 204 for two snapshots (e.g., using lineage information from the snapshot metadata), the delta in terms of block differences between two snapshots can be identified. Thus, by knowing the source snapshot for a read only recovery volume 106B and a target snapshot specified within an incremental restore operation, the block storage servers 105 can identify the delta between the target and source snapshot, and satisfy the incremental restore operation request by retrieving those blocks from the object storage servers 110 (e.g., by retrieving the objects 202 containing those blocks) and writing those blocks to a target volume. Where the target volume is a read only recovery volume 106B, no further data transfer may be required. Instead, the server 105 may mark the previously read only recovery volume 106B as writable, transforming it into a read/write block storage volume 106A. Where the target volume is a new volume (e.g., a newly created read/write block storage volume 106A), the remaining data of the target snapshot can be retrieved from the read only recovery volume 106B, which may be accessible to the target volume via a faster network connection than between the target volume and the object storage services 110 (e.g., in terms of more bandwidth, lower latency, or a combination thereof). Thus, the target volume can be restored to match the data in the target snapshot without requiring that all data of the target snapshot be transferred from the object storage servers 110.).
Although Nagapudi substantially teaches the claimed invention, Nagapudi does not explicitly indicate difference data is smaller than the difference amount.
Dayal teaches the limitations by stating
when the difference amount of the parent-child difference data is smaller than (Dayal col. 15 lines 14-49 e.g. … In various embodiments, the snapshot data determined to be sent from the source system to the destination system comprises a delta determined based at least in part on the snapshot index of the selected snapshot and the snapshot index of another snapshot stored at the source system. For example, the other snapshot may be one on which the selected snapshot depends (e.g., links to). Sending deltas between snapshot data (e.g., indices) is much more efficient than sending expanded states of snapshots, as is conventionally done. In some cases, a smaller delta may be created by comparing with a younger, rather than older snapshot. In some embodiments, inserting the snapshot data into the existing snapshot sequence at the destination system includes removing entries from the snapshot index of an existing snapshot relative to the snapshot data (refactoring, as will be described in further detail below), adding a new snapshot data (e.g., index) to the snapshot data sequence at the destination system to represent at the destination system the point-in-time data state associated with the selected snapshot, and/or changing the dependencies of the snapshot indices at the snapshot data sequence at the destination system to accommodate the addition of the new snapshot index) the difference amount of the inter-generation difference data.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of Nagapudi and Dayal, to overcome the drawback of transmission to and storage of expanded states of data at a destination system can be inefficient (Dayal col. 1 lines 24-25).
11. With respect to claim 2,
Nagapudi further discloses
each of the snapshot volumes is created by duplicating the volume (Nagapudi col. 2 line 26 – col. 3 line 3, col. 6 lines 22-42, col. 15 lines 46-63, col. 16 lines 26-54 e.g. duplicated), and
data is writable into the snapshot volume after creation (Nagapudi col. 4 line 9 – col. 5 lines 11, 33-45, col. 6 lines 43-55, col. 12 lines 11-45, col 13 line 1 – col. 15 lines 45 e.g. write; written; overwriting).
12. With respect to claim 3,
Nagapudi further discloses wherein the migration source storage node compares the volume with the plurality of snapshot volumes, extracts the parent-child difference data and the inter-generation difference data, and determines the parent-child difference data or the inter-generation difference data to be transferred to the migration destination storage node (Nagapudi Abstract, col. 4 line 42 – col. 5 line 32, col. 12 line 46 – col. 13 line 21, col. 14 lines 12-36).
13. With respect to claim 4,
Nagapudi further discloses
the migration source storage node transfers the inter-generation difference data, and
the migration destination storage node copies a snapshot image between generations of the snapshot volume of the migration destination storage node (Nagapudi Abstract, col. 4 line 42 – col. 5 line 32, col. 12 line 46 – col. 13 line 21, col. 14 lines 12-36).
Response to Argument
14. On pages 5-9, Applicant alleges the presently claimed invention, when viewed as a whole as required, is
directed to an improvement to storage systems.
Examiner disagrees because:
There is nothing in the instant applicant’s specification, such as [0003] – [0004] and Fig. 10, describes the presently claimed invention, when viewed as a whole as required, is directed to an improvement to storage systems.
15. On pages 9-13, Applicant alleges neither Nagapudi or Dayal discloses the specific comparison technique or the specific transfer technique set forth in claim 1. That is, the prior art of record does not disclose "compares a sum of difference amounts of parent-child difference data indicating differences between the volume as a migration target and the plurality of snapshot volumes with a sum of difference amounts of intergeneration difference data indicating inter-generation differences between the plurality of snapshot volumes, and transfers the parent-child difference data to the migration destination storage node upon determining the difference amount of the parent-child difference data is smaller than the difference amount of the intergeneration difference data, and transfers the inter-generation difference data to the migration destination storage node upon determining the difference amount of the inter-generation difference data is smaller than the difference amount of the parent-child difference data," as set forth in claim 1.
Examiner disagrees because:
Applicant’s arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Further, as described in Nagapudi
compares (e.g. comparison; comparing; compare - compare the manifests for two snapshots and identify differences based on the different objects in each manifest (where a given different object indicates that the one or more blocks stored in that object are different between the two snapshots)) a sum (e.g. The difference between a snapshot and a "sibling" (e.g., two distinct snapshots each created from a common parent) can be represented as the sum of deltas between the parent and each child) of difference amounts (e.g. differences) of parent-child difference (e.g. parent-child) data indicating differences between the volume (e.g. volume) as a migration (e.g. migration; restore) target (e.g. target server) and the plurality of snapshot volumes (e.g. snapshot … volumes) with a sum (e.g. the difference between a child and a more distance direct predecessor snapshot (e.g., a "grandparent" or "great grandparent") can be represented as the sum of deltas between each generation … combine differences for each generationally link in a lineage tree between the two snapshots, in order to determine total differences between two snapshots) of difference amounts of inter-generation (e.g. between each generation … each generationally link in a lineage tree between the two snapshots) difference data indicating inter-generation differences between the plurality of snapshot volumes, and
transfers (e.g. transfer) the parent-child difference data (e.g. parent-child) to the migration (e.g. migration; restore) destination storage node upon determining the difference amount of the parent-child difference data is the difference amount of the inter-generation difference data (e.g. between each generation … each generationally link in a lineage tree between the two snapshots), and transfers (e.g. transfer) the inter-generation difference data to the migration destination storage node upon determining the difference amount of the inter-generation difference data is the difference amount (e.g. differences) of the parent-child difference data (e.g. parent-child) (Nagapudi Abstract, col. 4 line 42 – col. 5 line 32, col. 12 line 46 – col. 13 line 21, col. 14 lines 12-36 e.g. [abstract] Systems and methods are provided for conducting incremental restore operations on block storage volumes using an object-based snapshot. A full restore from an object-based snapshot can include copying all blocks of a data set from the object-based snapshot to a destination volume. …. Embodiments of the present disclosure provide for incremental restore operations, where a delta data set is transferred from the snapshot to the destination volume, representing data in the snapshot is not known to already exist on the volume or another available volume. (14) In addition to knowledge that an existing volume stores data corresponding to another snapshot, incremental restore can be based at least partly on knowledge of a delta between two snapshots. For example, a snapshot service can maintain snapshots within a hierarchical structure, with a root snapshot indicating a first known set of block values, and each "child" snapshot representing a difference in block values relative to a parent snapshot. In one embodiment, creation of a child snapshot may be incremental, such that only blocks of a volume that have changed since the prior "parent" snapshot are written to the service. These changed blocks then reflect the delta between the two snapshots. This process can be repeated to identify the delta (e.g., those blocks with different data) for any two snapshots within the hierarchy. For example, the difference between a child and a more distance direct predecessor snapshot (e.g., a "grandparent" or "great grandparent") can be represented as the sum of deltas between each generation. The difference between a snapshot and a "sibling" (e.g., two distinct snapshots each created from a common parent) can be represented as the sum of deltas between the parent and each child. …. Accordingly, deltas between any two related snapshots can be quickly identified within a snapshot hierarchy. Notably, these techniques do not require direct comparison of data within two snapshots, as the delta from a prior snapshot can be record when creating that snapshot. …. (15) In some embodiments, a snapshot service may further identify differences between unrelated snapshots. For example, the service may enable a block-by-block comparison of the two snapshots, to identify such differences. In some cases, block-by-block comparisons can be made more efficient based on storage of blocks. For example, a snapshot service may store blocks in objects (e.g., files). In some instances, each object may reflect a single block of a volume. In other instances, each object may reflect multiple blocks. …. The service may then identify identical object when their object identifiers match, and identify non-identical object when such identifiers do not match. By comparing the identifiers of all object within two snapshots, differences between the snapshots can be quickly identified. For example, a snapshot service may store for each snapshot a "manifest" that lists all objects making up the snapshot. The differences between two snapshots may then be determined by identifying all objects listed in the manifest for one snapshot but not in the manifest for the other (43) At block (3), the block store server 105 requests from the object storage server 110 a listing of block differences between the source and target snapshot. The server 110 then, at (4), identifies those differences. As noted above, the object storage server 110 may identify differences based on a variety of techniques. For example, the server 110 may maintain, for each snapshot, a manifest indicating objects of the snapshot. The server 110 may thus compare the manifests for two snapshots and identify differences based on the different objects in each manifest (where a given different object indicates that the one or more blocks stored in that object are different between the two snapshots). Where two snapshots are related in lineage (e.g., as part of the same lineage tree), the server 110 may identify different based on the relationship between the two snapshots. For example, the server 110 may maintain information identifying differences between a parent and child snapshot, and may combine differences for each generationally link in a lineage tree between the two snapshots, in order to determine total differences between two snapshots. On identifying the differences, the server 110 returns a listing of the differences at (5). The listing may include for example a listing of blocks (e.g., as identifiers, such as block 1, block 2, etc.), a listing of objects in the snapshot that contain altered blocks, or both. (38) To facilitate updating read only recovery volumes 106B based on snapshots, the block storage services 105 can support incremental snapshot restore operations, in which a snapshot restore operation can be completed based on retrieval of only a delta between a target snapshot (being restored) and a source snapshot for a source volume (e.g., a read only recovery volume 106B). The object storage services 110 can illustratively maintain information used to identify that delta. For example, the services 110 may store snapshot metadata 214 indicating relationships between various snapshots, such as organized into a hierarchy (e.g., a tree data structure) that associates snapshots by lineage from a root snapshot. As discussed above, each snapshot may be stored as a set of objects 202 within block storage buckets 111, along with a manifest 204 for the snapshot that lists objects of the snapshot. By comparing the manifests 204 for two snapshots (e.g., using lineage information from the snapshot metadata), the delta in terms of block differences between two snapshots can be identified. Thus, by knowing the source snapshot for a read only recovery volume 106B and a target snapshot specified within an incremental restore operation, the block storage servers 105 can identify the delta between the target and source snapshot, and satisfy the incremental restore operation request by retrieving those blocks from the object storage servers 110 (e.g., by retrieving the objects 202 containing those blocks) and writing those blocks to a target volume. Where the target volume is a read only recovery volume 106B, no further data transfer may be required. Instead, the server 105 may mark the previously read only recovery volume 106B as writable, transforming it into a read/write block storage volume 106A. Where the target volume is a new volume (e.g., a newly created read/write block storage volume 106A), the remaining data of the target snapshot can be retrieved from the read only recovery volume 106B, which may be accessible to the target volume via a faster network connection than between the target volume and the object storage services 110 (e.g., in terms of more bandwidth, lower latency, or a combination thereof). Thus, the target volume can be restored to match the data in the target snapshot without requiring that all data of the target snapshot be transferred from the object storage servers 110.), and described in Dayal col. 15 lines 14-49 when the difference amount of the parent-child difference data is smaller than (Dayal col. 15 lines 14-49 e.g. … In various embodiments, the snapshot data determined to be sent from the source system to the destination system comprises a delta determined based at least in part on the snapshot index of the selected snapshot and the snapshot index of another snapshot stored at the source system. For example, the other snapshot may be one on which the selected snapshot depends (e.g., links to). Sending deltas between snapshot data (e.g., indices) is much more efficient than sending expanded states of snapshots, as is conventionally done. In some cases, a smaller delta may be created by comparing with a younger, rather than older snapshot. In some embodiments, inserting the snapshot data into the existing snapshot sequence at the destination system includes removing entries from the snapshot index of an existing snapshot relative to the snapshot data (refactoring, as will be described in further detail below), adding a new snapshot data (e.g., index) to the snapshot data sequence at the destination system to represent at the destination system the point-in-time data state associated with the selected snapshot, and/or changing the dependencies of the snapshot indices at the snapshot data sequence at the destination system to accommodate the addition of the new snapshot index) the difference amount of the inter-generation difference data.
The combination of Nagapudi and Dayal reasonably describes the argued limitation of " of record does not disclose "compares a sum of difference amounts of parent-child difference data indicating differences between the volume as a migration target and the plurality of snapshot volumes with a sum of difference amounts of intergeneration difference data indicating inter-generation differences between the plurality of snapshot volumes, and transfers the parent-child difference data to the migration destination storage node upon determining the difference amount of the parent-child difference data is smaller than the difference amount of the intergeneration difference data, and transfers the inter-generation difference data to the migration destination storage node upon determining the difference amount of the inter-generation difference data is smaller than the difference amount of the parent=child difference data".
Conclusion
16. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SyLing Yen whose telephone number is 571-270-1306.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sanjiv Shah can be reached at 571-272-4098. The fax and phone numbers for the organization where this application or proceeding is assigned is 571-273-8300.
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist whose telephone number is 571-272-2100.
/SYLING YEN/Primary Examiner, Art Unit 2166
September 28, 2026
Prosecution Insights