DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. 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
2. 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 January 28, 2026 has been entered.
Response to Amendment
3. This Office Action is responsive to the applicant’s request for continued examination (RCE) filed on January 28, 2026.4. Claims 1, 5-17, 21-33, and 37-48 are pending. Claims 1, 17, and 33 are in independent form5. Claim 1, 17, and 33 are amended.6, Claims 2-4, 18-20, and 34-36 are cancelled by the applicant.
Response to Arguments
7. Applicant’s arguments with respect to claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Information Disclosure Statement
8. The information disclosure statement (IDS) submitted on January 28, 2026, March 12, 2026, and May 05, 2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS is being considered by the examiner.
Claim Rejections - 35 USC § 103
9. 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 (i.e., changing from AIA to pre-AIA ) 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.
10. 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.
11. The factual inquiries 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.
12. Claims 1, 5-17, 21-33, and 37-48 are rejected under 35 U.S.C. 103 as being unpatentable over Chari et al. US 2015/0033223 A1 (hereinafter Chari) in view of Sawhney et al. US 2018/0121239 A1 (hereinafter Sawhney) further in view of Hajare et al. US Patent 10,949,309 B2 (hereinafter Hajare).
Regarding claim 1, Chari discloses a system comprising: a memory having computer-readable instructions stored thereon (Chari [0006] e.g., “…computer implemented instructions, which may be located in a memory”, see also [0006] e.g., “According to one illustrative embodiment, a computer system for sanitizing a virtual machine image of sensitive data is provided”. See also [0037] e.g., “…persistent storage 208 stores virtual machine image manager 218, virtual machine image 220, labeler 222, sanitizer 224…”); and a processor that executes the computer-readable instructions (Chari [0035] e.g., “Processor unit 204 serves to execute instructions…”, see also [0034] e.g., “… data processing system 200 includes communications fabric 202, which provides communications between processor unit 204, memory 206, persistent storage 208…”) to: transmit, from a database protection entity of a database management system to an agent of the database management system, a first snapshot capture request to capture a snapshot of a virtual machine from a source database located on a first site, the snapshot captured according to a first policy associated with the source database (Chari [0068]-[0069] e.g., “Virtual machine image 500 comprises virtual machine image software stack 502…”. “…virtual machine image software stack 502 includes applications 504, middleware 506, guest operating system 508, and virtual storage 510”. See also [0062] e.g., “… application data, such as raw data in database files; and application credentials, such as default passwords for applications”. This supports the idea that the object being snapshotted is a VM image hosting database data and configuration. This also shows that includes examples of sensitive data in VM images), wherein the snapshot includes an encapsulation of the virtual machine on which the source database is created, including configuration data of the virtual machine, data stored within the database, and metadata associated with the virtual machine (Chari [0068] e.g., “Virtual machine image 500 comprises virtual machine image software stack 502. Virtual machine image software stack 502 is a collection of a plurality of software components that comprises the functionality of virtual machine image 500”, see also [0069] e.g., “…virtual machine image software stack 502 includes applications 504, middleware 506, guest operating system 508, and virtual storage 510”. See also [0062] e.g., “…raw information in virtual disk blocks; sensitive details in system configuration files including…application data, such as raw data in database files; and application credentials”. Taken together, a snapshot of the VM image (as in lifecycle step [Figure 6, element 614 and Figure 9, element 914) is an encapsulation including VM configuration files, database files, and associated metadata); responsive to determining that the captured snapshot is to be sanitized, transmit, from the database protection entity to the agent of the database management system, based on the second policy, a clone request to create a clone of the source database using the captured snapshot (Chari [0074] e.g., “…the virtual machine image manager generates a snapshot of the specific instance …at 614”, see also [0096] e.g., “Furthermore, the virtual machine image manager generates a clone of the specific instance of the virtual machine image at 920…labels and sanitizes the cloned specific instance of the virtual machine image at 922 and stores the labeled and sanitized clone of the specific instance of the virtual machine image at 924”. This similar flow in the labeling/sanitization process: Snapshot 914 label/sanitize snapshot 916 and clone 920 label/sanitize clone 922. This is extremely close to the claim “snapshot … clone … sanitize clone” sequence); transmit, from the database protection entity to the agent of the database management system, based on the second policy, a sanitize request to apply a user defined masking script to the clone of the source database (Chari [0085] e.g., “Sanitizer 800 includes sanitization scripts 804, sanitization policies 806, and sanitization script execution policies 808…Sanitization scripts 804 are programming language developed in, for example, Perl script, Python script, shell script, or any other programming language. Sanitization scripts 804 apply sanitization policies 806…As a result, sanitization scripts 804 output sanitized specific instance of virtual machine image 810. In addition, sanitization scripts 804 also may update a sanitization history … set the next sanitization process, event, and/or time if it is a regularly scheduled process”. These statements map directly to a user-defined “masking script” i.e., a script that modifies sensitive data in the cloned database image according to policy); transmit, from the database protection entity to the agent of the database management system, based on the second policy, a second snapshot capture request to capture a sanitized snapshot from the clone of the source database to which the masking script has been applied (Chari [0095] e.g., “Further, the virtual machine image manager generates a snapshot of the specific instance of the virtual machine image at 914. … In addition, the virtual machine image manager labels and sanitizes the snapshot of the specific instance of the virtual machine image at 916 and stores the labeled and sanitized snapshot of the specific instance of the virtual machine image at 918.”, see also [0096] e.g., “Furthermore, the virtual machine image manager generates a clone … In addition, the virtual machine image manager labels and sanitizes the cloned specific instance of the virtual machine image at 922 and stores the labeled and sanitized clone of the specific instance of the virtual machine image at 924.”. This shows snapshots and clones being sanitized and then stored, conceptually equivalent to taking a snapshot after sanitization of a clone). Chari does not explicitly disclose: determine, by the database protection entity, based on a second policy, that the captured snapshot is to be sanitized and replicated to a second site, the second policy identifying which snapshots to sanitize; and whether to replicate the snapshots after sanitization, location where to replicate the snapshots after , sanitization to and for how long to maintain the snapshots after sanitization at the location. Sawhney discloses determine, by the database protection entity, based on a second policy, that the captured snapshot is to be sanitized and replicated to a second site, the second policy identifying which snapshots to sanitize (Sawhney [0034] e.g., “The object processing scheduler 102 may analyze policies corresponding to a container … to determine how and when to process the object”. This maps to “determine” and “based on a second policy” because the scheduler analyzed policies to determine subsequent processing action. ,The policies may explicitly indicate how and when objects within the container are to be processed”, see also [0036] e.g., “Examples of processing an object include, but are not limited to deleting the object, modifying the object, moving the object,…”. This helps support deciding to perform further processing operations on the snapshot/object, including transfer/synchronization type operations analogous to replication. See also [0042] e.g., “… a schedule may specify a first time (e.g., one week after creation) at which the object is to be moved from primary storage to secondary storage”. This support the claim limitation “replicate sanitized snapshot to second site”. See also [0041] e.g., “The policies may explicitly indicate how and when objects within the container are to be processed”. This supports policies selecting which objects receive processing treatment. See also [0034] e.g., “…determine how and when to process objects”. Together they support policy-based selection of objects/snapshots for downstream operations), whether to replicate the snapshots after sanitization (Sawhney [0034] e.g., “…determine how and when to process the object”), see also [0036] e.g., “Examples of processing an object include … moving the object, synchronizing the object…”. These supports a policy deciding whether transfer/synchronization occurs), location where to replicate the snapshots after , sanitization to (Sawhney [0027] e.g., “…object reference may be stored with information indicating that a corresponding object is to be transferred from a current data tier … to a different data tier …”,see also [0042] e.g., “…moved from primary storage to secondary storage”. These clearly shows destination/location-based storage transfer decisions), and for how long to maintain the snapshots after sanitization at the location (Sawhney [0042] e.g., “…a schedule may specify a first time … [and] a second time…”, see also [0029] e.g., “A time bucket is associated with a time period… Object references 109, within a particular time bucket, reference objects 110 that are to be processed during the time interval …”. This reinforce time-governed lifecycle management). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the sanitization and policy framework of Chare with the policy-based object processing and lifecycle management techniques of Sawhney in order to automate when and how virtual machine images, snapshots, or related data objects are processed, transferred, retained, or deleted according to defined policies, thereby improving management efficiency and reducing manual administration in distributed storage and cloud computing environments. incorporate the location-information acquisition. The combined teaching of Chari and Sawhney does not explicitly disclose: transmit, from the database protection entity to the agent of the database management system, based on the second policy, a delete request to delete the clone of the source database upon capturing the sanitized snapshot; and transmit, from the database protection entity to the agent of the database management system, based on the second policy, a replication request to replicate the sanitized snapshot to the second site. Hajare discloses transmit, from the database protection entity to the agent of the database management system, based on the second policy, a delete request to delete the clone of the source database upon capturing the sanitized snapshot (Hajare [col. 11, line 14-29] e.g., “Various snapshot commands may be synchronously implemented for the first snapshot and the second snapshot. In an example, responsive to receiving a delete snapshot command … and a second delete snapshot command… may be synchronously implemented”. This gives explicit controller-level delete commands for snapshot-derived objects, which can be applied by analogy to deletion of the intermediate clone once its sanitized snapshot has been captured); and transmit, from the database protection entity to the agent of the database management system, based on the second policy, a replication request to replicate the sanitized snapshot to the second site (Hajare [col. 9, lines 48-57] e.g., “A second storage controller may host a second storage object that is a backup replication of the first storage object. A synchronous replication relationship may be established between the first storage object and the second storage object…”. See also [col. 10, lines 18-29] e.g., “The splitter may split the write operation into a replication write operation. The splitter may instruct the first storage controller to locally implement the write operation upon the first storage object and instruct the second storage controller to remotely implement the replication write operation upon the second storage object.”, see also [col. 12, lines 47-67] e.g., “… the first snapshot 460 and the second snapshot 462 may correspond to a common snapshot of a data consistent state … and thus the second storage controller 410 can use the second snapshot 462 for disaster recovery purposes in the event the first storage controller 404 fails … responsive to a failover from a first site … to a second site,…”. These excerpts provide the core: a snapshot at a primary site and replicated snapshot at a secondary site, under control of a workflow). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the snapshot management and replication techniques of Hajare with the sanitization policy framework of Chari and the policy-based object lifecycle management of Sawhney in order to automate the capture, sanitization, retention, deletion, and replication of the virtual machine or database snapshots according to defined policies across distrusted storage environments, thereby improving security, reducing exposure of sensitive data, and reducing manual administrative overhead.
Claims 17 and 33 incorporate substantively all the limitations of claim 1 in a non-transitory computer-readable medium and a method and are rejected under the same rationale.
(Canceled)
(Canceled)
(Canceled)
Regarding claim 5, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 1, wherein the first site and the second site are part of different datacenters (Hajare [col. 1, lines 28-36] e.g., “In an example, the second storage cluster may be located at a remote site to the first storage cluster (e.g., storage clusters may be located in different buildings, cities, thousands of kilometers from one another, etc.)”. see also [col. 4, lines 50-67] e.g., “a first cluster of nodes such as the nodes 116, 118 (e.g., a first set of storage controllers configured to provide access to a first storage aggregate comprising a first logical grouping of one or more storage devices) … A second cluster of nodes, not illustrated, may be located at a second storage site … disaster recovery configuration”. These teachings reasonably disclose geographically separated datacenter environments).
Regarding claim 6, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 1, wherein each of the first site and the second site is part of a cloud environment (Hajare [col. 4, lines 33-49] e.g., “…cloud storage (e.g., a storage endpoint may be stored within a data cloud)..”, see also [col. 6, lines 24-44] e.g., “…snapshot creation may be implemented for and/or between… a cloud computing environment… transferrable between physical devices… and/or a cloud computing environment”). It would have been obvious to implement the disclosed replicated storage sites within cloud environments because the reference expressly contemplates cloud deployment architectures.
Regarding claim 7, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 1, wherein the first site is part of an on-premise environment and the second site is part of a cloud environment (Hajare [col. 6, lines 24-44] e.g., “…transferrable between physical devices … and/or a cloud computing environment”. See also [col. 5, lines 50-67] e.g., “… a first storage site … a second storage site… a disaster recovery configuration”). It would have been obvious to configure one site as a local/on-premise deployment and another site as a cloud deployment as a predictable hybrid disaster recovery architecture.
Regarding claim 8, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 1, wherein the first site is part of a cloud environment and the second site is part of an on-premise environment (Hajare [col. 4, lines 33-49] e.g., “… cloud storage”, see also [col. 6, lines 24-44] e.g., “…a cloud computing environment …” see also [col. 4, line 3-11] e.g., “…storage systems and/or nodes located in a plurality of geographic locations … a clustered network can include data storage systems (e.g., 102, 104) residing in a same geographic location”. Reversing primary/secondary deployment locations between cloud and on-premise environments would have been an obvious design choice depending on deployment preferences, cost, disaster recovery policy, or infrastructure ownership).
Regarding claim 9, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 1, wherein the processor further executes computer-readable instructions to: capture a transactional log from the source database based on the first policy; and replicate the transactional log to a third site upon capturing (Chari [0062] e.g., “…sensitive details in system logs, … application data, such as raw data in database files;” see also [0077] e.g., “…presence or absence of particular sensitive data items within, for example, data caches or system logs.”; and replicate the transactional log to a third site upon capturing (Sawhney [0042] e.g., “…moved from primary storage to secondary storage…”, see also [0036] e.g., “…Examples of processing an object include … moving the object, synchronizing the object…”. This support cross-location transfer/replication operation. A transactional log in a database system is fundamentally a type of log file associated with database/application operations. One of ordinary skill in the art would have understood transactional logs associated with database operations to be a type of database/application log file containing sensitive data subject to the disclosed sanitization policies).
Regarding claim 10, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 9, wherein to replicate the transactional log to the third site, the processor further executes computer-readable instructions to: store the transactional log in a stage drive on the first site (Sawhney [0027] e.g., “Another object reference may be stored with information indicating that a corresponding object is to be transferred from a current data tier (e.g., primary data tier) to a different data tier (e.g., a secondary data tier) …”); capture a staging snapshot of the stage drive on the first site (Sawhney [0037] e.g., “… store a system state … A stored system state may be referred to as a “checkpoint” saved””); replicate the staging snapshot from the stage drive on the first site to a stage drive on the third site (Sawhney [0042] e.g., “…moved from primary storage to secondary storage…”, see also [0036] e.g., “…Examples of processing an object include … moving the object, synchronizing the object…”. This support cross-location transfer/replication operation); and move the staging snapshot from the stage drive on the third site to a log drive on the third site (Sawhney [0036] e.g., “…Examples of processing an object include … moving the object, synchronizing the object…”, see also [0027] e.g., “… transferred from a current data tier (e.g., primary data tier) to a different data tier (e.g., a secondary data tier)”, see also [0042] e.g., “…moved from primary storage to secondary storage…”. These collectively support moving stored objects/snapshots between different storage locations/drives after replication).
Regarding claim 11, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 1, wherein the processor further executes computer-readable instructions to: determine, based on the second policy, that the captured snapshot is also to be replicated to a third site without sanitization (Sawhney [col. 10, lines 30-47] e.g., “…a second snapshot request may be sent to the second storage controller…”); and replicate the captured snapshot to the third site (Sawhney [col. 12, lines 47-67] e.g., “…the second storage controller 410 can use the second snapshot 462 for disaster recovery…”).
Regarding claim 12, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 1, wherein the first policy comprises a Service Level Agreement and a protection schedule to capture the snapshot and a transactional log from the source database on the first site (Chari [0059] e.g., “… service level management provides cloud computing resource allocation and management such that required service levels are met based on service level agreements.”. This teaches management policies associated with virtual machine management and sanitization operations may comprise serve level agreements).
Regarding claim 13, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 1, wherein the first policy and the second policy are defined at the time of creating the source database (Sawhney [0034] e.g., “The object processing scheduler 102 may analyze information about Object Mutation Events (OMEs) published by a component of a storage system to determine how and when to process an object”, see also [0041] e.g., “A policy, corresponding to a container which includes the object, may identify a secondary storage for transferring objects out of the primary storage”. This teaches policies associated with stored data objects/database content from the outset of managed storage processing).
Regarding claim 14, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 13, wherein each of the first policy and the second policy is configured to be updated after creation of the source database (Sawhney [0054] e.g., “…the configuration for the object specifies that the object is to be processed after 8:29 pm. Based on the modification, the metadata for the object is updated to indicate that the object is to be processed…”, see also [0033] e.g., “An optimal configuration for time buckets may change as a system scales up or scales down … the configuration of time buckets may be modified”. These expressly teach: policy/configuration modification after creation, and updating processing behavior dynamically over time).
Regarding claim 15, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 1, wherein the first policy is defined at the time of creating the source database and the second policy is defined after creating the source database (Sawhney [0034] e.g., “The object processing scheduler 102 may analyze information about Object Mutation Events (OMEs) published by a component of a storage system to determine how and when to process an object”, see also [0041] e.g., “A policy, corresponding to a container which includes the object, may identify a secondary storage for transferring objects out of the primary storage”. This teaches policies associated with stored data objects/database content from the outset of managed storage processing).
Regarding claim 16, the proposed combination of Chari, Sawhney, and Hajare teaches the system of claim 1, wherein the first policy comprises a first Service Level Agreement defining retention of the captured snapshot on the first site and the second policy comprises a second Service Level Agreement defining the retention of the sanitized snapshot on the second site (Chari [0059] e.g., “… service level management provides cloud computing resource allocation and management such that required service levels are met based on service level agreements.”. This teaches management policies associated with virtual machine management and sanitization operations may comprise serve level agreements).
18.(Canceled)
19. (Canceled)
20.(Canceled)
Regarding claim 21, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 17, wherein the first site and the second site are part of different datacenters (Hajare [col. 1, lines 28-36] e.g., “In an example, the second storage cluster may be located at a remote site to the first storage cluster (e.g., storage clusters may be located in different buildings, cities, thousands of kilometers from one another, etc.)”. see also [col. 4, lines 50-67] e.g., “a first cluster of nodes such as the nodes 116, 118 (e.g., a first set of storage controllers configured to provide access to a first storage aggregate comprising a first logical grouping of one or more storage devices) … A second cluster of nodes, not illustrated, may be located at a second storage site … disaster recovery configuration”. These teachings reasonably disclose geographically separated datacenter environments).
Regarding claim 22, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 17, wherein each of the first site and the second site is part of a cloud environment (Hajare [col. 4, lines 33-49] e.g., “…cloud storage (e.g., a storage endpoint may be stored within a data cloud)..”, see also [col. 6, lines 24-44] e.g., “…snapshot creation may be implemented for and/or between… a cloud computing environment… transferrable between physical devices… and/or a cloud computing environment”). It would have been obvious to implement the disclosed replicated storage sites within cloud environments because the reference expressly contemplates cloud deployment architectures.
Regarding claim 23, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 17, wherein the first site is part of an on-premise environment and the second site is part of a cloud environment (Hajare [col. 6, lines 24-44] e.g., “…transferrable between physical devices … and/or a cloud computing environment”. See also [col. 5, lines 50-67] e.g., “… a first storage site … a second storage site… a disaster recovery configuration”). It would have been obvious to configure one site as a local/on-premise deployment and another site as a cloud deployment as a predictable hybrid disaster recovery architecture.
Regarding claim 24, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 17, wherein the first site is part of a cloud environment and the second site is part of an on-premise environment (Hajare [col. 4, lines 33-49] e.g., “… cloud storage”, see also [col. 6, lines 24-44] e.g., “…a cloud computing environment …” see also [col. 4, line 3-11] e.g., “…storage systems and/or nodes located in a plurality of geographic locations … a clustered network can include data storage systems (e.g., 102, 104) residing in a same geographic location”. Reversing primary/secondary deployment locations between cloud and on-premise environments would have been an obvious design choice depending on deployment preferences, cost, disaster recovery policy, or infrastructure ownership).
Regarding claim 25, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 17, wherein the processor further executes computer-readable instructions to: capture a transactional log from the source database based on the first policy; and replicate the transactional log to a third site upon capturing (Chari [0062] e.g., “…sensitive details in system logs, … application data, such as raw data in database files;” see also [0077] e.g., “…presence or absence of particular sensitive data items within, for example, data caches or system logs.”. A transactional log in a database system is fundamentally a type of log file associated with database/application operations. One of ordinary skill in the art would have understood transactional logs associated with database operations to be a type of database/application log file containing sensitive data subject to the disclosed sanitization policies).
Regarding claim 26, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 25, wherein to replicate the transactional log to the third site, the processor further executes computer-readable instructions to: store the transactional log in a stage drive on the first site (Sawhney [0027] e.g., “Another object reference may be stored with information indicating that a corresponding object is to be transferred from a current data tier (e.g., primary data tier) to a different data tier (e.g., a secondary data tier) …”); capture a staging snapshot of the stage drive on the first site (Sawhney [0037] e.g., “… store a system state … A stored system state may be referred to as a “checkpoint” saved””); replicate the staging snapshot from the stage drive on the first site to a stage drive on the third site (Sawhney [0042] e.g., “…moved from primary storage to secondary storage…”, see also [0036] e.g., “…Examples of processing an object include … moving the object, synchronizing the object…”. This support cross-location transfer/replication operation); and move the staging snapshot from the stage drive on the third site to a log drive on the third site (Sawhney [0036] e.g., “…Examples of processing an object include … moving the object, synchronizing the object…”, see also [0027] e.g., “… transferred from a current data tier (e.g., primary data tier) to a different data tier (e.g., a secondary data tier)”, see also [0042] e.g., “…moved from primary storage to secondary storage…”. These collectively support moving stored objects/snapshots between different storage locations/drives after replication).
Regarding claim 27, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 17, wherein the processor further executes computer-readable instructions to: determine, based on the second policy, that the captured snapshot is also to be replicated to a third site without sanitization (Sawhney [col. 10, lines 30-47] e.g., “…a second snapshot request may be sent to the second storage controller…”); and replicate the captured snapshot to the third site (Sawhney [col. 12, lines 47-67] e.g., “…the second storage controller 410 can use the second snapshot 462 for disaster recovery…”).
Regarding claim 28, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 17, wherein the first policy comprises a Service Level Agreement and a protection schedule to capture the snapshot and a transactional log from the source database on the first site (Chari [0059] e.g., “… service level management provides cloud computing resource allocation and management such that required service levels are met based on service level agreements.”. This teaches management policies associated with virtual machine management and sanitization operations may comprise serve level agreements).
Regarding claim 29, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 17, wherein the first policy and the second policy are defined at the time of creating the source database (Sawhney [0034] e.g., “The object processing scheduler 102 may analyze information about Object Mutation Events (OMEs) published by a component of a storage system to determine how and when to process an object”, see also [0041] e.g., “A policy, corresponding to a container which includes the object, may identify a secondary storage for transferring objects out of the primary storage”. This teaches policies associated with stored data objects/database content from the outset of managed storage processing).
.
Regarding claim 30, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 29, wherein each of the first policy and the second policy is configured to be updated after creation of the source database (Sawhney [0054] e.g., “…the configuration for the object specifies that the object is to be processed after 8:29 pm. Based on the modification, the metadata for the object is updated to indicate that the object is to be processed…”, see also [0033] e.g., “An optimal configuration for time buckets may change as a system scales up or scales down … the configuration of time buckets may be modified”. These expressly teach: policy/configuration modification after creation, and updating processing behavior dynamically over time).
Regarding claim 31, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 17, wherein the first policy is defined at the time of creating the source database and the second policy is defined after creating the source database (Sawhney [0034] e.g., “The object processing scheduler 102 may analyze information about Object Mutation Events (OMEs) published by a component of a storage system to determine how and when to process an object”, see also [0041] e.g., “A policy, corresponding to a container which includes the object, may identify a secondary storage for transferring objects out of the primary storage”. This teaches policies associated with stored data objects/database content from the outset of managed storage processing).
Regarding claim 32, the proposed combination of Chari, Sawhney, and Hajare teaches the non-transitory computer-readable medium of claim 17, wherein the first policy comprises a first Service Level Agreement defining retention of the captured snapshot on the first site and the second policy comprises a second Service Level Agreement defining the retention of the sanitized snapshot on the second site (Chari [0059] e.g., “… service level management provides cloud computing resource allocation and management such that required service levels are met based on service level agreements.”. This teaches management policies associated with virtual machine management and sanitization operations may comprise serve level agreements).
34.(Canceled)
35.(Canceled)
36.(Canceled)
Regarding claim 37, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 33, wherein the first site and the second site are part of different datacenters (Hajare [col. 1, lines 28-36] e.g., “In an example, the second storage cluster may be located at a remote site to the first storage cluster (e.g., storage clusters may be located in different buildings, cities, thousands of kilometers from one another, etc.)”. see also [col. 4, lines 50-67] e.g., “a first cluster of nodes such as the nodes 116, 118 (e.g., a first set of storage controllers configured to provide access to a first storage aggregate comprising a first logical grouping of one or more storage devices) … A second cluster of nodes, not illustrated, may be located at a second storage site … disaster recovery configuration”. These teachings reasonably disclose geographically separated datacenter environments).
Regarding claim 38, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 33, wherein each of the first site and the second site is part of a cloud environment (Hajare [col. 4, lines 33-49] e.g., “…cloud storage (e.g., a storage endpoint may be stored within a data cloud)..”, see also [col. 6, lines 24-44] e.g., “…snapshot creation may be implemented for and/or between… a cloud computing environment… transferrable between physical devices… and/or a cloud computing environment”). It would have been obvious to implement the disclosed replicated storage sites within cloud environments because the reference expressly contemplates cloud deployment architectures.
Regarding claim 39, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 33, wherein the first site is part of an on-premise environment and the second site is part of a cloud environment (Hajare [col. 6, lines 24-44] e.g., “…transferrable between physical devices … and/or a cloud computing environment”. See also [col. 5, lines 50-67] e.g., “… a first storage site … a second storage site… a disaster recovery configuration”). It would have been obvious to configure one site as a local/on-premise deployment and another site as a cloud deployment as a predictable hybrid disaster recovery architecture.
Regarding claim 40, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 33, wherein the first site is part of a cloud environment and the second site is part of an on-premise environment (Hajare [col. 4, lines 33-49] e.g., “… cloud storage”, see also [col. 6, lines 24-44] e.g., “…a cloud computing environment …” see also [col. 4, line 3-11] e.g., “…storage systems and/or nodes located in a plurality of geographic locations … a clustered network can include data storage systems (e.g., 102, 104) residing in a same geographic location”. Reversing primary/secondary deployment locations between cloud and on-premise environments would have been an obvious design choice depending on deployment preferences, cost, disaster recovery policy, or infrastructure ownership).
Regarding claim 41, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 33, further comprising: capturing, by the processor, a transactional log from the source database based on the first policy (Chari [0062] e.g., “…sensitive details in system logs, … application data, such as raw data in database files;” see also [0077] e.g., “…presence or absence of particular sensitive data items within, for example, data caches or system logs.” A transactional log in a database system is fundamentally a type of log file associated with database/application operations. One of ordinary skill in the art would have understood transactional logs associated with database operations to be a type of database/application log file containing sensitive data subject to the disclosed sanitization policies); and replicating, by the processor, the transactional log to a third site upon capturing (Sawhney [0042] e.g., “…moved from primary storage to secondary storage…”, see also [0036] e.g., “…Examples of processing an object include … moving the object, synchronizing the object…”. This support cross-location transfer/replication operation).
Regarding claim 42, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 41, further comprising: storing, by the processor, the transactional log in a stage drive on the first site (Sawhney [0027] e.g., “Another object reference may be stored with information indicating that a corresponding object is to be transferred from a current data tier (e.g., primary data tier) to a different data tier (e.g., a secondary data tier) …”); capturing, by the processor, a staging snapshot of the stage drive on the first site (Sawhney [0037] e.g., “… store a system state … A stored system state may be referred to as a “checkpoint” saved””); replicating, by the processor, the staging snapshot from the stage drive on the first site to a stage drive on the third site (Sawhney [0042] e.g., “…moved from primary storage to secondary storage…”, see also [0036] e.g., “…Examples of processing an object include … moving the object, synchronizing the object…”. This support cross-location transfer/replication operation); and moving, by the processor, the staging snapshot from the stage drive on the third site to a log drive on the third site (Sawhney [0036] e.g., “…Examples of processing an object include … moving the object, synchronizing the object…”, see also [0027] e.g., “… transferred from a current data tier (e.g., primary data tier) to a different data tier (e.g., a secondary data tier)”, see also [0042] e.g., “…moved from primary storage to secondary storage…”. These collectively support moving stored objects/snapshots between different storage locations/drives after replication).
Regarding claim 43, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 33, further comprising: determining, by the processor and based on the second policy, that the captured snapshot is also to be replicated to a third site without sanitization (Sawhney [col. 10, lines 30-47] e.g., “…a second snapshot request may be sent to the second storage controller…”); and replicating, by the processor, the captured snapshot to the third site (Sawhney [col. 12, lines 47-67] e.g., “…the second storage controller 410 can use the second snapshot 462 for disaster recovery…”).
Regarding claim 44, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 33, wherein the first policy comprises a Service Level Agreement and a protection schedule to capture the snapshot and a transactional log from the source database on the first site (Chari [0059] e.g., “… service level management provides cloud computing resource allocation and management such that required service levels are met based on service level agreements.”. This teaches management policies associated with virtual machine management and sanitization operations may comprise serve level agreements).
Regarding claim 45, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 33, wherein the first policy and the second policy are defined at the time of creating the source database (Sawhney [0054] e.g., “…the configuration for the object specifies that the object is to be processed after 8:29 pm. Based on the modification, the metadata for the object is updated to indicate that the object is to be processed…”, see also [0033] e.g., “An optimal configuration for time buckets may change as a system scales up or scales down … the configuration of time buckets may be modified”. These expressly teach: policy/configuration modification after creation, and updating processing behavior dynamically over time).
Regarding claim 46, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 45, wherein each of the first policy and the second policy is configured to be updated after creation of the source database (Sawhney [0054] e.g., “…the configuration for the object specifies that the object is to be processed after 8:29 pm. Based on the modification, the metadata for the object is updated to indicate that the object is to be processed…”, see also [0033] e.g., “An optimal configuration for time buckets may change as a system scales up or scales down … the configuration of time buckets may be modified”. These expressly teach: policy/configuration modification after creation, and updating processing behavior dynamically over time).
Regarding claim 47, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 33, wherein the first policy is defined at the time of creating the source database and the second policy is defined after creating the source database (Sawhney [0034] e.g., “The object processing scheduler 102 may analyze information about Object Mutation Events (OMEs) published by a component of a storage system to determine how and when to process an object”, see also [0041] e.g., “A policy, corresponding to a container which includes the object, may identify a secondary storage for transferring objects out of the primary storage”. This teaches policies associated with stored data objects/database content from the outset of managed storage processing).
Regarding claim 48, the proposed combination of Chari, Sawhney, and Hajare teaches the method of claim 33, wherein the first policy comprises a first Service Level Agreement defining retention of the captured snapshot on the first site and the second policy comprises a second Service Level Agreement defining the retention of the sanitized snapshot on the second site (Chari [0059] e.g., “… service level management provides cloud computing resource allocation and management such that required service levels are met based on service level agreements.”. This teaches management policies associated with virtual machine management and sanitization operations may comprise serve level agreements)..
Conclusion
13. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BERHANU MITIKU whose telephone number is (571)270-1983. The examiner can normally be reached Monday – Friday 8:30AM – 4:00PM.
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, Ajay Bhatia can be reached at 571-272-3906. 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.
/BERHANU MITIKU/Examiner, Art Unit 2156
/AJAY M BHATIA/Supervisory Patent Examiner, Art Unit 2156
Prosecution Insights