Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on June 3, 2026 has been entered.
Response to Amendment
In response to the amendment filed on June 3, 2026:
Claims 1, 9, 11, 19, and 21 are amended.
Claims 8, and 18 are canceled.
Claims 1-7, 9-17, and 19-22 are pending.
Response to Arguments
In response to the remarks filed on June 3, 2026:
Applicant’s remarks towards the 35 U.S.C. 102(a)(1) and 103 rejections of the pending claims have been fully considered but are moot in view of a new ground of rejections presented here on.
Claim Rejections - 35 USC § 101
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.
The claimed invention in claims 1-7, 9-17, and 19-22 are directed to a judicial exception (i.e., an abstract idea) without significantly more.
Claims 1-7, 9-17, and 19-22 pass step 1 of the 35 U.S.C. 101 analysis since each claim is either directed to a method, a system comprising a memory and a processing device (i.e., hardware components [0033]-[0039] of specification), or non-transitory computer readable storage medium.
a. Claims 1, 11, and 21 recite in each claims elements that are directed to an abstract idea of mental processes and/or certain methods of organizing human activity (specifically, managing and organizing stored information/data). Each claim recites the core steps of taking a point-in-time reference copy of selected data (snapshotting) and copying/transferring such data to another destination container that already holds pre-existing data (replicating to a non-empty container) which fundamentally belong to a process of collecting, organizing, manipulating, and transmitting data. These functional operations represent steps that can be performed via a mental processes or human administrative ledgering (e.g., noting the current state of a ledger/file, verifying that a target repository holds unrelated files, and making a copy of the recorded state into that target repository). Gathering, organizing, and transmitting data (such as backing up, copying, or snapshotting data sets) without reciting a concrete technical architecture or specific algorithmic mechanism falls squarely within subject matter categorized as an abstract idea per step 2A – prong 1 of the abstract idea analysis (see, e.g., Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350 (Fed. Cir. 2016); Content Extraction and Transmission LLC v. Wells Fargo Bank, Nat’l Ass’n, 776 F.3d 1343 (Fed. Cir. 2015)).
Per step 2A – prong 2 of the analysis, the claim limitations, considered both individually and as an ordered combination, fail to integrate the abstract idea into a practical application because they do not improve the functioning of a computer or other technology nor do they apply the exception in a meaningful technological way.
Lack of Improvement to Computer Functionality: while the specification may describe technical efficiencies (e.g., copy-on-write extent-graph pointers, background delta updates, or non-disruptive migration), these technical solutions are not set forth in the claim language. The independent claims recite the generation and replication of data at a high level of functional abstraction (i.e., generating a snapshot…; and replicating the snapshot…).
State of the Target Pod: the recitation that the target pod includes another data set that is different from the data set of the source pod merely specifies the environmental state/contents of the target container before copying. Restricting an abstract data copying operation to a container that already contains distinct data is merely an informational constraint on data placement rather than a technical improvement to storage functioning.
Per step 2B of the analysis, the claims do not recite an inventive concept sufficient to transform the abstract idea into a patent-eligible application.
The hardware and structural elements recited, i.e., storage system, volumes, virtual volumes, portions of a file system, and pods, are described and claimed in terms of their generic storage capabilities (storing, grouping, and addressing data blocks/files). The recitation of these generic components performing their routing computer functions does not supply an inventive concept (Alice Corp. Pty. Ltd. V. CLS Bank Int’s, 574 U.S. 208, 225 (2014)).
Taking snapshots of volumes/file systems, replicating snapshots between storage containers (whether local, remote, or across multiple pods), and checking for differences between source and target data before transmission are well-understood, routine, and conventional (WURC) activities in the data storage field.
Simply confining data replication to target containers that already contain existing heterogeneous data sets (i.e., another data set that is different) amounts to field-of-use data management or extra-solution organization. It does not provide any technical transformation nor does it tie the process to a specific, unconventional technological protocol.
b. Dependent claims 2-7, 9-10, 12-17, 19-20, and 22:
Claims 2-3, 12-13, and 22 merely recite broad structural locations for the pods (co-located on a single storage system or across two storage systems) which represent WURC deployment options for distributed data.
Claims 4, and 14 each recites identifying missing data and sending only the missing data which is generic deduplication/differential replication expressed as pure functional results without reciting any concreate protocol or data structure.
Claims 5-6, and 15-16 recite that the first storage system comprises a plurality of systems using synchronous replication or near-synchronous replication which merely invokes WURC replication modes at a high level of generality.
Claims 7, and 17 each recites 1-to-many replication, i.e., to a plurality of target pods, which is WURC data distribution.
Claims 9, and 19 each recites bidirectional replication, i.e., replicating another snapshot…from the target pod to the source pod) which merely repeats the abstract steps of their respective independent claims in the reverse direction.
Claims 10, and 20 each recites that the pods are associated with different tenants of the storage system which simply characterizes data ownership/business organization (multi-tenancy) and constitutes a method of organizing human commercial relationships.
Because these dependent claims (1) do not integrate the abstract concept into an improvement in computer functioning, nor impose meaningful technical limits on execution, and (2) do not provide any technical transformation or tie to a specific unconventional technological protocol, the dependent claims remain directed to an abstract idea under step 2A – Prong 2 and step 2B.
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 1-6, 10-16, and 20-22 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Botes et al. (Pub. No. US 2018/0260125, published on September 13, 2018; hereinafter Botes) in view of Martin et al. (Pub. No. US 2019/0034321, published on January 31, 2019; hereinafter Martin).
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 original pods, as well as allowing isolation to a single site (or a few sites) separately from the original pod, [0209]).
Martin then discloses replicating the snapshot of the data set to an existing target pod different than the source pod, wherein the target pod includes another data set that is different from the data set of the source pod (records may be removed before being copied to the original sandbox tenant and/or the new sandbox tenants so that sensitive information that may be included in customer records is not provided to outside developers. The original sandbox may be configured with test data using the template, and one or more copies of the original sandbox may be made to create one or more new sandbox tenants, [0014]. The original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data may be changed without changing the original tenant data, and the original tenant data may be changed without changing the sandbox tenant data, [0026]-[0027]. It is clear that the target environment contains data distinct from the source data as shown by disclosing the target sandbox includes its own separately stored sandbox data in addition to the snapshot-derived source data. Each sandbox having access to a virtual snapshot of the original sandbox data while separately storing new data generated by the new sandbox. Each sandbox/tenant is described as an independently addressable environment having its own identifier or namespace, access rules, snapshot-derived data, and subsequently generated data. These are the functional characteristics of a distinct logical container as an identifiable grouping of data with its own namespace, access boundary, snapshot view, and independently managed changes).
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 Martin with the teachings of Botes for the purpose of introducing a snapshot-derive dataset into an existing target environment thereby preserving separation between the replicated dataset and data of the existing target environment to support data manipulation without overwriting, corrupting, or duplicating data already associated with the destination.
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]).
Claims 7, and 17 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Botes in view of Martin and further 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, as modified by Martin, 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.
Claims 9, and 19 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Botes in view of Martin and further in view of Mitkar et al. (Pub. No. US 2017/0262520, published on September 14, 2017; hereinafter Mitkar).
Regarding claims 9, and 19, Mitkar then discloses replicating another snapshot of another data set included in the target pod from the target pod to the source pod (Because the failover site 203 can be maintained in a synchronized, “warm” state, the downtime for switching over from the production site 201 to the destination site 203 is substantially less than with a typical restore from secondary storage. Thus, the production site 201 may flexibly and efficiently fail over, with minimal downtime and with relatively up-to-date data, to a destination site 203, such as a cloud-based failover site. The destination site 203 can then be reverse synchronized back to the production site 201, such as after repairs have been implemented or after the failure has passed, [0262]. It is clear that snapshots capturing the state of a storage device, file system, or volume at a particular time. After the destination/failover site has received the first replicated snapshot and has acquired or generated changed data, the destination contains data different from the original source data. A subsequent snapshot of that destination data can be reverse synchronized to the original production site).
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 Mitkar with the teachings of Botes, as modified by Martin, for the purpose of supporting disaster recovery, fail back, and resynchronization within an information management system after the target has become the active or modified copy to enable faster information management operations, and enhanced scalability of the information management system.
Pertinent Prior Art
The following references are considered relevant to the claims:
Karunanithi et al. (Pub. No. 2019/0155801) teaches validating a target data table of a target data store based on a source data table of a source data store remote from the target data store, each of the target data table and the source data table including one or more rows and one or more columns for storing data elements, can comprise loading the source data table and the target data table into a distributed memory comprising a plurality of computing systems, each computing system in data communication with at least one of the source data store or the target data store to receive at least a portion of the source data table and the target data table and configured to store the portion in a local random access memory such that the distributed memory includes the entirety of the source data table and the target data table.
Voss et al. (Pub. No. 2018/0322184) teaches receiving a statement from a client application of the first tenant database. A transaction log is generated based on the statement and sent to the target system to replay the transaction log at the second tenant database of the target system. In response to processing the statement by first tenant database, information is sent to the client application that indicates completion of processing the statement. Topology information associated with a tenant databases includes information corresponding to tables associated with the tenant database, and information corresponding to table partitions associated with the tenant database.
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 September 8, 2026
Prosecution Insights