DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
In response to the amendment filed on December 22, 2025:
Claims 1-6, 9, 11-17, and 19 are amended.
Claims 8, and 18 are canceled.
Claims 21-22 are newly added.
Claims 1-7, 9-17, and 19-22 are pending.
Response to Arguments
In response to the remarks filed on December 22, 2025:
Applicant’s remarks towards the 35 U.S.C. 102(a)(1) and 103 rejections of claims 1-7, 9-17, and 19-20 have been fully considered but are not persuasive.
Applicant remarks that Botes does not teach or disclose “wherein the data set comprises one or more volumes of the source pod, one or more virtual volumes of the source pod, or one or more portions of a file system of the source pod” in independent claims 1, and 11. The Examiner respectfully disagrees. Botes describes the pod as including managed objects that are subject to access operations ([0182]) and that a pod can be used to implement virtual arrays or virtual storage systems (Pods can also be used to implement virtual arrays or virtual storage systems where each pod is presented as a unique storage entity on a network (e.g., a Storage Area Network…), [0183]-[0184]). Indeed, Botes explicitly discloses that data set is equivalent to pod’s volumes or snapshot (i.e., claimed volumes of the source pod) (since each pod has an independent copy of all data and metadata needed to operate on the pod content, it is a straightforward problem to make a virtual copy of some or all volumes or snapshots in the pod to new volumes in a new pod. In a logical extent graph implementation, for example, all that is needed is to define new volumes in a new pod which reference logical extent graphs from the copied pod associated with the pod's volumes or snapshots, and with the logical extent graphs being marked as copy on write. The new volumes should be treated as new volumes, similarly to how volume snapshots copied to a new volume might be implemented, [0207]).
Lastly, in the context of the synchronous replicating architecture described by Botes, the managed objects are the discrete units of storage being replicated. In the field of storage area networks (SAN), it is well-known that a virtual storage system presented on a SAN, by technical necessity, is composed of logical volumes or virtual volumes (commonly referred to as LUNs). A dataset existing within such a virtual array cannot be accessed by a host unless it is structured as one or more volumes. A person skilled in the art would recognize that for a dataset to be read or modified via in IP network, such dataset must be instantiated as one or more volumes or virtual volumes. Thus, Botes clearly discloses the limitation as claimed.
Rejections of all dependent claims associated with claims 1, and 11 are also maintained for the at least reasons presented above.
Newly added claims 21-22 are also rejected as presented below.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-6, 10-16, and 20-22 are rejected under AIA 35 U.S.C. 102(a)(1) as being anticipated by Botes et al. (Pub. No. US 2018/0260125, published on September 13, 2018; hereinafter Botes).
Regarding claims 1, 11, and 21, Botes clearly show and discloses a method (Abstract), a system comprising: a memory; and a processing device, operatively coupled to the memory, the processing device configured to implement the method; and a non-transitory computer readable storage medium storing instructions that, when executed, cause a processing device to implement the method (Figure 1A) comprising:
generating a snapshot of a data set included in a source pod of a storage system (allowing for a snapshot of an offline pod, to be copied to a new pod with new volumes that have sufficiently new identities that host I/O drivers and clustered applications won't confuse the copied volumes as being the same as the still online volumes on another storage system. Since each pod maintains a complete copy of the dataset, which is crash consistent but perhaps slightly different from the copy of the pod dataset on another storage system, and since each pod has an independent copy of all data and metadata needed to operate on the pod content, it is a straightforward problem to make a virtual copy of some or all volumes or snapshots in the pod to new volumes in a new pod, [0207]), wherein the data set comprises one or more volumes of the source pod, one or more virtual volumes of the source pod, or one or more portions of a file system of the source pod (Pods can also be used to implement virtual arrays or virtual storage systems where each pod is presented as a unique storage entity on a network (e.g., a Storage Area Network, or Internet Protocol network) with separate addresses. In the case of a multi-storage-system pod implementing a virtual storage system, all physical storage systems associated with the pod may present themselves as in some way the same storage system (e.g., as if the multiple physical storage systems were no different than multiple network ports into a single storage system), [0182]-[0184]. Since each pod has an independent copy of all data and metadata needed to operate on the pod content, it is a straightforward problem to make a virtual copy of some or all volumes or snapshots in the pod to new volumes in a new pod. In a logical extent graph implementation, for example, all that is needed is to define new volumes in a new pod which reference logical extent graphs from the copied pod associated with the pod's volumes or snapshots, and with the logical extent graphs being marked as copy on write. The new volumes should be treated as new volumes, similarly to how volume snapshots copied to a new volume might be implemented, [0207]); and
replicating the snapshot of the data set to a target pod different than the source pod (Virtually copying a pod (or set of pods) to another pod as a point-in-time image of the pod datasets immediately creates an isolated dataset that contains all the copied elements and that can then be operated on essentially identically to the originally pods, as well as allowing isolation to a single site (or a few sites) separately from the original pod, [0209]).
Regarding claims 2, 12, and 22, Botes further discloses the source pod and the target pod are in a first storage system (a simple migration of a volume from a first pod to a second pod even for two pods that share the same first and second storage systems, [0217]).
Regarding claims 3, and 13, Botes further discloses the source pod is in a first storage system and the target pod is in a second storage system (allowing for an offline pod, or perhaps a snapshot of an offline pod, to be copied to a new pod with new volumes that have sufficiently new identities that host I/O drivers and clustered applications won't confuse the copied volumes as being the same as the still online volumes on another storage system, [0207]).
Regarding claims 4, and 14, Botes then discloses replicating the snapshot of the data set to the target pod (since each pod has an independent copy of all data and metadata needed to operate on the pod content, it is a straightforward problem to make a virtual copy of some or all volumes or snapshots in the pod to new volumes in a new pod, [0207]) comprises :
identifying data referenced by the snapshot not stored in the second storage system (If a block is found to have already been stored by the first storage system, that storage system can use its reference to name the reference in each of the additional storage systems (either because the reference uses the same hash value or because an identifier for the reference is either identical or can be mapped readily), [0405]); and
providing the data from the first storage system (Recovery in such a store may then include comparing recently updated block references for a volume. If block references differ between different in-sync storage systems for a pod, then one version of each reference can be copied to other storage systems to make them consistent. If the block reference on one system does not exist, then it be copied from some storage system that does store a block for that reference, [0405]).
Regarding claims 5, and 15, Botes further discloses the first storage system is comprised of a plurality of storage systems (Figure 4 shows multiple storage systems 402-406, including a can be attached or detached to/from an existing pod, [0181]-[0182]).
Regarding claims 6, and 16, Botes further discloses at least a subset of the plurality of storage systems replicate the source pod using synchronous replication or near-synchronous replication (Having, a preferred storage system may not be as useful for providing high availability, but may be useful for other uses of synchronous replication, particularly asymmetric synchronous replication. Take for example, the case of mirroring a pod from a central, large storage system in a data center or campus, to a smaller (perhaps less managed) storage system running closer to application servers, such as in top-of-rack configurations, [0347]).
Regarding claims 10, and 20, Botes further discloses the source pod and the target pod are associated with different tenants of the storage system (pods can be used to implement tenants, whereby datasets are in some way securely isolated from each other, [0183]).
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.
Claims 7, 9, 17, and 19 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Botes in view of Singh et al. (Pub. No. US 2020/0311025, filed on July 30, 2019; hereinafter Singh).
Regarding claims 7, and 17, Singh then discloses replicating the snapshot of the data set to the target pod comprises replicating the snapshot of the data set to a plurality of target pods including the target pod (the snapshots are replicated to distributed computing system 1022 as a set of replicated snapshots 126 (operation 1). In this case, distributed computing system 1021 can be considered a primary site 112 and distributed computing system 1022 can be considered a secondary site 114. In some cases, subject snapshots 122 are replicated to multiple sites, [0033]).
It would have been obvious to an ordinary person skilled in the art at the time of the invention was effectively filed to incorporate the teachings of Singh with the teachings of Botes for the purpose of enabling snapshots from a first cluster to be replicated to a second cluster to maintain high availability data and data restoration in failover events.
Regarding claims 9, and 19, Singh further discloses replicating another snapshot of another data set from the target pod to the source pod (the failover event might be invoked by a node failure at distributed computing system 1021 that affects one or more virtualized entities (e.g., VMs, vDisks, etc.). The snapshots needed to perform the failover are identified (operation 634) and a failover associated with the snapshots at distributed computing system 1022 is requested (message 636), [0091]-[0092]).
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Son Hoang whose telephone number is (571) 270-1752. The Examiner can normally be reached on Monday – Friday (7:00 AM – 4:00 PM).
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Sherief Badawi can be reached on (571) 272-9782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SON T HOANG/ Primary Examiner, Art Unit 2169 March 31, 2026
Prosecution Insights