Office Action 2: Final Rejection (2024-06-06)
Rejection types: 103 - Obviousness

CLAIMS:
AMENDMENTS TO THE CLAIMS

Please add or amend the claims to read as follows, and cancel without prejudice or disclaimer to resubmission in a divisional or continuation application claims indicated as cancelled:

1\. (Currently Amended) A storage system, comprising:storage nodes; and
compute nodes;
wherein the compute nodes comprise:
source compute nodes that are configured to (a) receive, during source storage periods, write requests for storing content in the storage system, (b) write, during the source storage periods, the content into the storage nodes, and (c) remain non-operational during replication periods; and
replication compute nodes that are configured to (a) read the content from the storage nodes during the replication periods, (b) participate in outputting the content to one or more data recovery sites during the replication periods, and (c) remain non-operational during the source storage periods.

2\. (Currently Amended) The storage system according to claim 12wherein the source compute nodes are exposed to user computers that are external to the storage system, via an external network; wherein the replication compute nodes are not connected to the external network.

3\. (Currently Amended) The storage system according to claim 1. wherein the replication compute nodes are configured to participate in the outputting by reading the content from the storage nodes and sending the content to at least one of output ports or communication units of the storage system.

4\. (Currently Amended) The storage system according to claim 12wherein the source compute nodes are in communication with a first network that is at least in part external to the storage system and wherein the replication compute nodes are in communication with the one or more data recovery sites via a second network that is at least in part external to the storage system and differs from the first network.

5\. (Currently Amended) The storage system according to claim 1,wherein the storage nodes are configured to undergo a reboot process at beginnings of the replication period.

6\. (Currently Amended) The storage system according to claim 1,comprising a controller that is configured to dynamically allocate compute nodes of the storage system to act as replication compute nodes or as source compute nodes.

7\. (Currently Amended) The storage system according to claim 1,comprising a controller that is configured to deactivate the replication compute nodes during the source storage periods, deactivate the source compute nodes during the replication periods, activate replication compute nodes during the replication periods, and activate the source compute nodes during the source storage periods.

8\. (Currently Amended) The storage system according to claim 12wherein at least some of the compute nodes comprise a deactivation unit for selectively activating and deactivating one or more compute nodes.

9\. (Currently Amended) The storage system according to claim 1,comprising a controller that is configured to control a timing of the source storage periods and to control a timing of the replication periods.

10\. (Currently Amended) The storage system according to claim 1,wherein at least some of the compute nodes are configured to control a timing of the source storage periods and a timing of the replication periods.

11\. (Currently Amended) A method for protecting a disaster recovery site, the method comprises:receiving by source compute nodes of a storage system, during source storage periods, write requests for storing content in the storage system,
writing by source compute nodes, during the source storage periods, the content into storage nodes of the storage system;
maintaining replication compute nodes of the storage system in a non-operational mode during the source storage periods;
reading the content by the replication compute nodes from the storage nodes during replication periods;
participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods;
maintaining the source compute nodes in a non-operational mode during the source storage periods.

12\. (Currently Amended) The method according to claim 111wherein the source compute nodes are exposed to user computers that are external to the storage system, via an external network; wherein the replication compute nodes are not connected to the external network.

13\. (Currently Amended) The method according to claim 11,comprising participating, by the replication compute nodes, in the outputting by reading the content from the storage nodes and sending the content to at least one of output ports or communication units of the storage system.

14\. (Currently Amended) The method according to claim 111wherein the source compute nodes are in communication with a first network that is at least in part external to the storage system and wherein the replication compute nodes are in communication with the one or more data recovery sites via a second network that is at least in part external to the storage system and differs from the first network.

15\. (Currently Amended) The method according to claim 111comprising rebooting the storage nodes at beginnings of the replication period.

16\. (Currently Amended) The method according to claim 111comprising dynamically allocating the compute nodes to act as replication compute nodes or as source compute nodes.

17\. (Currently Amended) The method according to claim 111comprising deactivating, by a controller, replication compute nodes during the source storage periods; deactivating the source compute nodes during the replication periods, activating the replication compute nodes during the replication periods, and activating the source compute nodes during the source storage periods.

18\. (Currently Amended) The method according to claim 11,comprising selectively activating and deactivating one or more compute nodes by one or more deactivation units of one or more of the compute nodes.

19\. (Currently Amended) The method according to claim 11,controlling, by a controller, a timing of the source storage periods and a timing of the replication periods.

20\. (Currently Amended) The method according to claim 111comprising controlling, by at least some of the compute nodes, a timing of the source storage periods and a timing of the replication periods.

21\. (Currently Amended) A non-transitory computer readable medium that stores instructions for:receiving by source compute nodes of a storage system, during source storage periods, write requests for storing content in the storage system;
writing by source compute nodes, during the source storage periods, the content into storage nodes of the storage system;
maintaining replication compute nodes of the storage system inanon-operational mode during the source storage periods;
reading the content by the replication compute nodes from the storage nodes during replication periods;
participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods; and
maintaining the source compute nodes in a non-operational mode during the source storage periods.

OFFICE ACTION:
DETAILED ACTION
Notice of Pre-AIA  or AIA  Status
1.	This action is responsive to communication filed on 18 April 2024, with acknowledgement of an original application filed on 26 October 2021.
Status of Claims
2.	Claims 1-21 are pending. Claims 1, 11, and 21 are in independent forms. Claims 1-21 has been amended.                                                                               Drawings
3.	The drawings filed on September 09/01/2021 are accepted by the examiner.
Remarks
4. 	The claim objection withdrawn based on the amendment to the objected claims.
Response to Arguments                                                                                                                                                                            5.    	Applicant's arguments filed 18 April 2024 have been fully considered but they are not persuasive.
I) 	In response to applicant's arguments on pages 7-8, Applicant argued that while Zafman teaches that both the receiving from the client and the replication can be performed by the same storage node, claim 1 recites that these two steps are performed by different compute nodes of the storage system. Furthermore, claim 1 recites that these different steps are not only performed by different compute nodes, but also at different time periods:  the receiving of write requests from the user is done during source storage periods, while the outputting to one or more data recovery sites is done during replication periods.  Zafman does not mention time separation between the reception of write requests and the replication to other storage nodes.
.
The examiner respectfully disagrees with the argument. The applicant argued that the Zafman reference fails to disclose receive, during source storage periods, write requests for storing content in the storage system. Contrary to the applicant assertion, as stated in the office action the Zafman reference discloses the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both. Furthermore, Zafman discloses the storage system 104 can receive read and write requests from the client device 102 and distribute them among the storage nodes 106a-d, which can service those requests. The storage system 104 may determine how to distribute the read and write requests among the storage nodes 106a-d based on the load on the storage system 104 or other factors, such as if one or more of the storage nodes 106a-d has failed. the storage system can repeated at predefined intervals during a timespan to dynamically adjust how many replicas of content are stored in the storage system over the timespan, based on the amount of load on the storage system at different points in time during the timespan. updating the replicas for a piece of content asynchronously over a time period after receiving a write request, so that all of the replicas are “eventually” consistent with one another. Asynchronous replication can introduce less latency into the storage system than synchronous replication, which involves updating all of the replicas synchronously so that they are all “immediately” consistent with one another. But asynchronous replication can also decrease the durability of the storage system. This is because if the storage system fails in the intervening time period before all of the replicas are updated, there are fewer up-to-date replicas from which to pull data  (see Zafman pars. 0002, 0011-0017).                                                                                                                             II. 	The amended non-operational addressed in the body of  the rejection below.
Claim Rejections - 35 USC § 103
6.	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.
7.	Claims 1-21 are rejected under 35 U.S.C. 103 as being unpatentable over Zafman et al. US Patent Application Publication No. 2021/0191634 (hereinafter Zafman) in view of Grunwald US Patent Application Publication No. 2021/0081432 (hereinafter Grunwald).
Regarding claim 1,  Zafman discloses a storage system (Fig. 1, storing system 104), comprising:
“storage nodes” (Fig. 1, storage nodes 106 a-d); and “compute nodes” (Fig. 1, storing system 104); wherein the compute nodes comprise:
“source compute nodes that are configured to (a) receive, during source storage periods, write requests for storing content in the storage system (see Zafman par. 0024, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both), (b) write, during the source storage periods, the content into the storage nodes (see Zafman par. 0025, the storage system 104 has received a write request 202 associated with the content 108 from the client devices 102. The storage system 104 can respond to the write request 202 by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both), and
“replication compute nodes that are configured to (a) read the content from the storage nodes during the replication periods (see Zafman par. 0015, the storage system 104 can receive a read request from the client device 102, determine that the storage nodes 106a-c have failed, and thus distribute the read request to storage node 106d, since the storage node 106d is the only remaining storage node that is operational);
Chen does not explicitly discloses (c) remain non-operational during replication periods; (b) participate in outputting the content to one or more data recovery sites during the replication periods; and (c) remain non-operational during the source storage periods.
However, in analogues art, Grunwald discloses (c) remain non-operational during replication periods (see Grunwald par. 0355, 0034, 0068 a replica link may be used to specify a replication relationship, and depending on whether a pod is active or passive, determines a direction of the replication, where replication occurs in the direction of an active (or activated or promoted) pod to a passive (or deactivated or demoted) pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server);  (b) participate in outputting the content to one or more data recovery sites during the replication periods (see Grunwald par. 0068, Control of storage locations and workloads are distributed across the storage locations in a clustered peer-to-peer system. Tasks such as mediating communications between the various storage nodes, detecting when a storage node has become unavailable, and balancing I/Os (inputs and outputs) across the various storage nodes, are all handled on a distributed basis. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server),  and (c) remain non-operational during the source storage periods (see Grunwald par. 0355, 0034, 0068, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server);
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 2 and 12,  Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses wherein the source compute nodes are exposed to user computers that are external to the storage system, via an external network (see Grunwald Fig. 2B, par. 0075, storage cluster 161 is enclosed within a single chassis 138. External port 176 is coupled to storage nodes 150 through communications interconnect 173); wherein the replication compute nodes are not connected to the external network (see Grunwald par. 0068, a storage cluster that stores user data, such as user data originating from one or more user or client systems or other sources external to the storage cluster. The storage cluster distributes user data across storage nodes housed within a chassis, or across multiple chassis, using erasure coding and redundant copies of metadata).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 3 and 13, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses wherein the replication compute nodes are configured to participate in the outputting by reading the content from the storage nodes and sending the content to at least one of output ports or communication units of the storage system (see Grunwald par. 0033, The storage drives 171A-F may respond by sending a response message to the storage array controller 110A-D that includes the location of control information for the storage drive 171A-F. Responsive to receiving the response message, storage array controllers 110A-D may issue a request to read data stored at the address associated with the location of control information for the storage drives 171A-F).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 4 and 14, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses wherein the source compute nodes are in communication with a first network that is at least in part external to the storage system and wherein the replication compute nodes are in communication with the one or more data recovery sites via a second network that is at least in part external to the storage system and differs from the first network (see Grunwald par. 0333, in response to a recovery event—such as a source data repository 602 losing a connection with a host computer (not depicted) or applications sending storage operations, performance degradation beyond a threshold value, storage capacity exceeding a threshold value, or a degradation in response times—the target data repository 624 may be promoted to handle all further storage operations from the host computer, and another data repository may be selected. In this example, the replica link from the original source data repository 602 to the target data repository 624 may be reconfigured to flip directions, where the target data repository 624 becomes a new source data repository and another data repository becomes a new target data repository, and where other replica link characteristics stay the same).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 5 and 15, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses wherein the storage nodes are configured to undergo a reboot process at beginnings of the replication period (see Grunwald par. 0212, Since each storage system will have its own copy of the list, and since two independent storage systems can't update their local copy at exactly the same time, and since the local copy is all that is available on a reboot or in various fault scenarios, care must be taken to ensure that transient inconsistencies don't cause problems. For example, if one storage systems is in-sync for a pod and a second storage system is added, then if the second storage system is updated to list both storage systems as in-sync first, then if there is a fault and a restart of both storage systems, the second might startup and wait to connect to the first storage system while the first might be unaware that it should or could wait for the second storage system).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 6 and 16, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses comprising a controller that is configured to dynamically allocate compute nodes of the storage system to act as replication compute nodes or as source compute nodes (see Grunwald par. 0335, there may be a dynamic relationship of volumes to pods, where the dynamic collection of volumes within a pod may be related to a clock value within the update stream on a source storage system. For example, a checkpoint may introduce volumes to a pod, change volume characteristics (name, size, etc.) and may remove volumes. In this example, if there are protection groups or some similar organizational concept within a pod, then these protection groups may also change with those changes being propagated through checkpoints. In this way, a near-sync target storage system may actually take over relatively seamlessly as a periodic replication source with all relationships intact, minus whatever time difference the last processed checkpoint is from the previous active source).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 7 and 17, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses comprising a controller that is configured to deactivate the replication compute nodes during the source storage periods, deactivate the source compute nodes during the replication periods, activate replication compute nodes during the replication periods, and activate the source compute nodes during the source storage periods (see Grunwald par. 0355, a replica link may be used to specify a replication relationship, and depending on whether a pod is active or passive, determines a direction of the replication, where replication occurs in the direction of an active (or activated or promoted) pod to a passive (or deactivated or demoted) pod. In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 8 and 18, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Grunwald further discloses wherein at least some of the compute nodes comprise a deactivation unit for selectively activating and deactivating one or more compute nodes (see Grunwald par. 0332, if for some reason, such as a recovery event on the source data repository 602 based on data loss or based on a user or application requesting access to the replica volume or based on a failover request to begin using the replica volume 634 as a primary or user-accessible volume, then the target data repository 624 may promote, or activate, the replica volume 634. In response, the existing checkpoints in the metadata log 626 may be replayed to generate a version of the tracking volume 632 consistent with a most recent checkpoint received, and the tracking volume 632 may be used to create a version of the source volume 658).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claims 9 and 19, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Zafman further discloses comprising a controller that is configured to control a timing of the source storage periods and to control a timing of the replication periods (see Zafman par. 0024, After generating the target number of replicas 110a-c in the storage system 104, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both. Updating replicas asynchronously may introduce less latency than synchronous replication. However, updating replicas asynchronously may also decrease the durability of the storage system 104, because if the storage system 104 fails in the intervening time period before all of the replicas 110a-c are updated, there are fewer up-to-date replicas from which to pull data).
Regarding claims 10 and 20, Zafman in view of Grunwald discloses the storage system according to claim 1, the method according to claim 11,
Zafman further discloses wherein at least some of the compute nodes are configured to control a timing of the source storage periods and a timing of the replication periods (see Zafman pars. 0010-0011, Asynchronous replication involves updating the replicas for a piece of content asynchronously over a time period after receiving a write request, so that all of the replicas are “eventually” consistent with one another. Asynchronous replication can introduce less latency into the storage system than synchronous replication, which involves updating all of the replicas synchronously so that they are all “immediately” consistent with one another. But asynchronous replication can also decrease the durability of the storage system. This is because if the storage system fails in the intervening time period before all of the replicas are updated, there are fewer up-to-date replicas from which to pull data).
Regarding claim 11, Zafman discloses a method for protecting a disaster recovery site, the method comprises:
“receiving by source compute nodes of a storage system, during source storage periods, write requests for storing content in the storage system” (see Zafman par. 0024, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“writing by source compute nodes, during the source storage periods, the content into storage nodes of the storage system” (see Zafman par. 0025, the storage system 104 has received a write request 202 associated with the content 108 from the client devices 102. The storage system 104 can respond to the write request 202 by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“reading the content by the replication compute nodes from the storage nodes during replication periods” (see Zafman par. 0015, the storage system 104 can receive a read request from the client device 102, determine that the storage nodes 106a-c have failed, and thus distribute the read request to storage node 106d, since the storage node 106d is the only remaining storage node that is operational);
Chen does not explicitly discloses maintaining the source compute nodes in a non-operational mode during the source storage periods; participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods; maintaining replication compute nodes of the storage system in a non-operational mode during the source storage periods.
However, in analogues art, Grunwald discloses maintaining the source compute nodes in a non-operational mode during the source storage periods see Grunwald par. 0355, 0034, 0068 a replica link may be used to specify a replication relationship, and depending on whether a pod is active or passive, determines a direction of the replication, where replication occurs in the direction of an active (or activated or promoted) pod to a passive (or deactivated or demoted) pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server);  participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods (see Grunwald par. 0068, Control of storage locations and workloads are distributed across the storage locations in a clustered peer-to-peer system. Tasks such as mediating communications between the various storage nodes, detecting when a storage node has become unavailable, and balancing I/Os (inputs and outputs) across the various storage nodes, are all handled on a distributed basis. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server),  maintaining replication compute nodes of the storage system in a non-operational mode during the source storage periods ((see Grunwald par. 0355, 0034, 0068, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server);
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
Regarding claim 21, Zafman discloses a non-transitory computer readable medium that stores instructions for:
“receiving by source compute nodes of a storage system, during source storage periods, write requests for storing content in the storage system” (see Zafman par. 0024, the storage system 104 may receive a write request associated with the content 108 from the client devices 102. In some examples, the storage system 104 can respond to such write requests by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“writing by source compute nodes, during the source storage periods, the content into storage nodes of the storage system” (see Zafman par. 0025, the storage system 104 has received a write request 202 associated with the content 108 from the client devices 102. The storage system 104 can respond to the write request 202 by updating the replicas 110a-c using asynchronous replication, synchronous replication, or both);
“reading the content by the replication compute nodes from the storage nodes during replication periods” (see Zafman par. 0015, the storage system 104 can receive a read request from the client device 102, determine that the storage nodes 106a-c have failed, and thus distribute the read request to storage node 106d, since the storage node 106d is the only remaining storage node that is operational);
Chen does not explicitly discloses maintaining replication compute nodes of the storage system in a non-operational mode during the source storage periods; participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods; and maintaining the source compute nodes in a non-operational mode during the source storage periods.
However, in analogues art, Grunwald discloses maintaining replication compute nodes of the storage system in a non-operational mode during the source storage periods (see Grunwald par. 0355, 0034, 0068, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server);  participating, by the replication compute nodes, in outputting the content to one or more data recovery sites during the replication periods (see Grunwald par. 0068, Control of storage locations and workloads are distributed across the storage locations in a clustered peer-to-peer system. Tasks such as mediating communications between the various storage nodes, detecting when a storage node has become unavailable, and balancing I/Os (inputs and outputs) across the various storage nodes, are all handled on a distributed basis. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server); and maintaining the source compute nodes in a non-operational mode during the source storage periods ((see Grunwald par. 0355, 0034, 0068, In this example, a replication direction may also be changed if all pods connected to the replica link are in communication and reach consensus on a change in replication direction. In this way, a source pod may be protected by creating a replica link to another, deactivated, pod on another data repository, where hosts or host groups may be connected to the deactivated pod on the target data repository to read—nearly synchronous—data from the source pod. Data is laid out or distributed across multiple storage nodes in data fragments or stripes that support data recovery in some embodiments. Ownership of data can be reassigned within a cluster, independent of input and output patterns. This architecture described in more detail below allows a storage node in the cluster to fail, with the system remaining operational, since the data can be reconstructed from other storage nodes and thus remain available for input and output operations. In various embodiments, a storage node may be referred to as a cluster node, a blade, or a server).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Grunwald in to the system of Zafman in order to provide if too many failures or replication events occur in too short a time period, the system goes into a self-preservation mode and halts replication and data movement activities until an administrator intervenes in accordance with some embodiments (see Grunwald par. 0086).
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 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 mailing date of this final action.

APPLICANT REBUTTAL: REMARKS
STATUS OF CLAIMS
Claims 1-21 are pending.
Claims 1-21 were rejected.
Claims 2-10 and 12-20 have been objected to.
Claims 1-21 and have been amended.
The support for the amendment can be found at least in paragraphs [0030], [0036]- [0037].
No new matter has been added.
Claim Objections
In the Office Action, the Examiner objected to claims 2-12 (should be: 2-10) and 12-20 because of alleged informalities. Claims 2-10 and 12-20 have been amended in order to cure these informalities. Accordingly, Applicants request withdrawal of the objection.
35 USC 103 REJECTIONS
Claims 1-21 stand rejected under 35 USC 103 as being unpatentable over Zafman et al. (US Publication 2021/0191634), hereinafter "Zafman", in view of Grunwald (US publication 2021/0081432), hereinafter "Grunwald".
This rejection is traversed.
Zafman teaches that a single storage node performs both the reception of write requests from the users as well as replicating the writes to other storage nodes that stores replicas. See for example paragraph [0024]:
...the storage system 104 may
receive a write request
associated with the content 108 from the client devices 102. In some examples, the storage system
can respond to
such write requests by
u
p
datin
g
the replicas
In contrast to Zafman that teaches that the same storage node is responsible for both receiving a write request from the client as well as replicating to other storage nodes, claim 1 of the present invention recites two types of compute nodes that differ from each other by the steps recited in claim 1 and that they are configured to perform: (i) the source compute nodes are configured to
receive write requests
for storing content in the storage system and to write the content into the storage nodes of the same storage system; (ii) the replication compute nodes perform different steps according to claim 1: outputing the content (that was written to the storage nodes of the storage system by the source compute nodes) to one or more
data recovery sites.
Therefore, while Zafman teaches that both the receiving from the client and the replication can be performed by the same storage node, claim 1 recites that these two steps are performed by different compute nodes of the storage system.
Furthermore, claim 1 recites that these different steps are not only performed by different compute nodes, but also
at different time periods:
the receving of write requests from the user is done during "source storage periods", while the outputing to one or more data recovery sites is done during "replication periods".
Zafman does not mention time separation between the receprion of write requests and the replication to other storage nodes.
In addition to performing the receprion of write requests and the replication at different time periods, claim 1 further recites that the source compute nodes are
configured
to
remain
non-operational during replication periods (when the replication compute nodes participate in the outputting to data recovery sites), and the replication compute nodes are
configured
to
remain
non-operational during the source storage periods (when the source compute nodes receive of write requests).
The Examiner asserts that the passive pod of Grunwald reads on "remain
non- operational
deactivated
during the source storage periods". The term "passive" described in paragraph [0355] referred to be the examiner, is defined as the target of the replication. A target of a replication is actually operational as it needs to be in communication with the source pod, to receive data from the source pod and to store it in its repository.
Furthermore, paragraph [0355] describes that the passive pod can be target to read requests from host groups. Accepting read requests is
an activity,
and therefore the passive pod cannot be considered as non-operational.
The problem solved by using separate compute nodes for receiving write requests and for participating in outputting to data recovery sites, and configured to be non-operational at different periods - is described in the present application, paragraphs [0029]-[0030].
Neither Zafman nor Grunwald, alone or in combination, teach or suggest all the features of claim 1.
The arguments for claim 1 are applicable to independent claims 11 and 21.
Conclusion

NEXT OFFICE ACTION: DETAILED ACTION
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 14 November, 2024 has been entered.
2.	Claims 1-21 are pending.
Response to Arguments
3.	Applicant’s arguments with respect to the rejection of the pending claims over prior arts of record have been fully considered and are persuasive.
Allowable Subject Matter
4.	Claims 1-21 are allowed. No reason for allowance is needed as the record is clear in light of further search conducted, claim amendments and applicant’s arguments filed on 11/04/2024.
Conclusion
5.	Any comments considered necessary by applicant must be submitted no later than the payment
of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such
submissions should be clearly labeled “Comments on statement of Reasons for Allowance”.

CITED REFERENCE SUMMARIES: Ref US20210191634A1: [content unavailable]
Ref US20210081432A1: Claims:
A method for using lightweight checkpoints in a data storage system, the method comprising: receiving, at a source data repository, one or more updates to one or more datasets stored within the source data repository; generating, based on the one or more updates to the one or more datasets, metadata describing the one or more updates to one or more datasets stored within the source data repository; and generating, based on the metadata describing the one or more updates to the one or more datasets, a lightweight checkpoint of metadata describing an ordered application of the one or more updates to the one or more datasets.
receiving, at a source data repository, one or more updates to one or more datasets stored within the source data repository;
generating, based on the one or more updates to the one or more datasets, metadata describing the one or more updates to one or more datasets stored within the source data repository; and
generating, based on the metadata describing the one or more updates to the one or more datasets, a lightweight checkpoint of metadata describing an ordered application of the one or more updates to the one or more datasets.
The method of claim 1 , further comprising: sending, from the source data repository to a target data repository and independent from sending the lightweight checkpoint to the target data repository, data corresponding to the lightweight checkpoint.
sending, from the source data repository to a target data repository and independent from sending the lightweight checkpoint to the target data repository, data corresponding to the lightweight checkpoint.
The method of claim 1 , wherein an ordered log of metadata includes one or more lightweight checkpoints.
The method of claim 3 , wherein a quantity of updates described by a given lightweight checkpoint is a configurable data replication setting.
The method of claim 3 , wherein the configurable data replication setting is target recovery point objective.
The method of claim 1 , wherein the recovery event is responsive to one or more of: a detected failure, a detected impending failure, or a detected degradation of responsiveness beyond a compliance policy threshold of the source data repository.
The method of claim 1 , wherein the recovery event is not based on a failure and is based on a promotion event to prepare, for testing on the target data repository, a replica of the stored data at the source data repository.
A storage system that includes a computer memory and a computer processor, the computer memory including program instructions that, when executed by the computer processor, cause the storage system to carry out the steps of: receiving, at a target data repository from a source data repository, metadata describing one or more updates to one or more datasets stored within the source data repository; generating, based on the metadata describing the one or more updates to the one or more datasets, an ordered log of metadata describing an ordered application of the one or more updates to the one or more datasets; and generating, based on the ordered log of metadata, the one or more datasets in accordance with the one or more updates.
receiving, at a target data repository from a source data repository, metadata describing one or more updates to one or more datasets stored within the source data repository;
generating, based on the metadata describing the one or more updates to the one or more datasets, an ordered log of metadata describing an ordered application of the one or more updates to the one or more datasets; and
generating, based on the ordered log of metadata, the one or more datasets in accordance with the one or more updates.
The storage system of claim 8 , wherein the program instructions, when executed by the computer processor, further cause the storage system to carry out the steps of: receiving, at the target data repository from the source data repository and independent from receiving the metadata describing the one or more updates to the one or more datasets, data corresponding to the one or more updates to the one or more datasets.
receiving, at the target data repository from the source data repository and independent from receiving the metadata describing the one or more updates to the one or more datasets, data corresponding to the one or more updates to the one or more datasets.
The storage system of claim 8 , wherein the ordered log of metadata includes one or more lightweight checkpoints.
The storage system of claim 10 , wherein a quantity of updates described by a given lightweight checkpoint on a configurable data replication setting.
The storage system of claim 10 , wherein the configurable data replication setting is target recovery point objective.
The storage system of claim 8 , wherein the recovery event is responsive to one or more of: a detected failure, a detected impending failure, or a detected degradation of responsiveness beyond a compliance policy threshold of the source data repository.
The storage system of claim 8 , wherein the recovery event is not based on a failure and is based on a promotion event to prepare, for testing on the target data repository, a replica of the stored data at the source data repository.
A method for continuous data protection, the method comprising: generating, based on the metadata describing the one or more updates to the one or more datasets, an ordered log of metadata describing an ordered application of the one or more updates to the one or more datasets; and generating, on the source data repository and based on the ordered log of metadata, at least a portion of the one or more datasets in accordance with the one or more updates corresponding to a specified point in time.
generating, on the source data repository and based on the ordered log of metadata, at least a portion of the one or more datasets in accordance with the one or more updates corresponding to a specified point in time.
The method of claim 16 , wherein stored data to generate the one or more datasets is available based on garbage collection on the source data repository using both a reference table maintained by a storage controller and also a list of references within the ordered log of metadata.
The method of claim 16 , wherein the ordered log of metadata includes one or more lightweight checkpoints.
The method of claim 16 , wherein a quantity of updates described by a given lightweight checkpoint on a configurable data replication setting.
The method of claim 19 , wherein a quantity of lightweight checkpoints stored on the source data repository is based on a configuration setting that specifies a recovery window of time.
Ref US20210191634: Claims:
1. A storage system comprising:
a processor; and a memory including instructions executable by the processor for causing the processor to:
determine an amount of load on the storage system based on values for performance metrics indicating a performance of the storage system;
determine that the storage system is to have a target number of replicas of content based on the amount of load on the storage system; and
adjust the storage system to have the target number of replicas of the content.
2. The storage system of claim 1, wherein the memory further includes instructions executable by the processor for causing the processor to adjust the storage system to have the target number of replicas by adding a predefined number of replicas of the content to the storage system, the predefined number of replicas being equal to a difference between a current number of replicas of the content in the storage system and the target number of replicas of the content, the target number of replicas being more than the current number of replicas.
3. The storage system of claim 1, wherein the memory further includes instructions executable by the processor for causing the processor to:
receive a write request for updating the content; in response to receiving the write request:
determine that a group of replicas of the content in the storage system is to be updated asynchronously based on the amount of load on the storage system; and
update the group of replicas in the storage system asynchronously.
4. The storage system of claim 3, wherein the group of replicas is a first group of replicas, and wherein the memory further includes instructions executable by the processor for causing the processor to, in response to receiving the write request:
determine that a second group of replicas of the content in the storage system is to be updated synchronously based on the amount of load on the storage system, the second group of replicas being different from the first group of replicas; and update the second group of replicas in the storage system synchronously.
5. The storage system of claim 1, wherein the memory further includes instructions executable by the processor for causing the processor to adjust the storage system to have the target number of replicas by removing a predefined number of replicas of the content from the storage system, the predefined number of replicas being equal to a difference between a current number of replicas of the content in the storage system and the target number of replicas of the content, the target number of replicas being less than the current number of replicas.
6. The storage system of claim 1, wherein the performance metrics include any combination of a load average associated with the storage system, a queue depth associated with the storage system, a tail latency associated with the storage system, or an amount of background activity associated with the storage system.
7. The storage system of claim 1, wherein the memory further includes instructions executable by the processor for causing the processor to repeatedly and dynamically adjust how many replicas of the content are stored in the storage system over a timespan based on the values for the performance metrics at different points in time during the timespan.
8. The storage system of claim 1, wherein the memory further includes instructions executable by the processor for causing the processor to determine the target number of replicas by supplying the values for the performance metrics as inputs to a machine-learning model and receiving the target number of replicas as output from the machine-learning model.
9. The storage system of claim 8, wherein the machine-learning model is trained using a training dataset comprising input-output pairs, each of the input-output pairs including (i) a respective load amount as input and (ii) a corresponding target number of replicas as output.
10. The storage system of claim 1, wherein the memory further includes instructions executable by the processor for causing the processor to, prior to determining the amount of load on the storage system:
determine relationships between the performance metrics and storage-system load by performing a regression analysis in which the performance metrics serve as independent variables and the storage-system load serves as a dependent variable; and select, based on the relationships, the performance metrics from among a group of candidate performance metrics for use in determining the amount of load on the storage system.
11. A method comprising:
determining, by a processor, an amount of load on a storage system based on values for performance metrics indicating a performance of the storage system; determining, by the processor, that the storage system is to have a target number of replicas of content based on the amount of load on the storage system; and adjusting, by the processor, the storage system to have the target number of replicas of the content.
12. The method of claim 11, further comprising adjusting the storage system to have the target number of replicas by adding a predefined number of replicas of the content to the storage system, the predefined number of replicas being equal to a difference between a current number of replicas of the content in the storage system and the target number of replicas of the content, the target number of replicas being more than the current number of replicas.
13. The method of claim 11, further comprising:
receiving a write request for updating the content; and in response to receiving the write request:
determining that a first group of replicas of the content in the storage system is to be updated asynchronously;
determining that a second group of replicas of the content in the storage system is to be updated synchronously, the second group of replicas being different from the first group of replicas; and
updating the first group of replicas in the storage system asynchronously and the second group of replicas in the storage system synchronously.
14. The method of claim 11, further comprising adjusting the storage system to have the target number of replicas by removing a predefined number of replicas of the content from the storage system, the predefined number of replicas being equal to a difference between a current number of replicas of the content in the storage system and the target number of replicas of the content, the target number of replicas being less than the current number of replicas.
15. The method of claim 11, wherein the performance metrics include any combination of a load average associated with the storage system, a queue depth associated with the storage system, a tail latency associated with the storage system, or an amount of background activity associated with the storage system.
16. The method of claim 11, further comprising repeatedly and dynamically adjusting how many replicas of the content are stored in the storage system over a timespan based on the values for the performance metrics at different points in time during the timespan.
17. The method of claim 11, further comprising determining the target number of replicas by supplying the values for the performance metrics as inputs to a machine-learning model and receiving the target number of replicas as output from the machine-learning model.
18. The method of claim 17, wherein the machine-learning model is trained using a training dataset comprising input-output pairs, each of the input-output pairs including (i) a respective load amount as input and (ii) a corresponding target number of replicas as output.
19. The method of claim 11, further comprising, prior to determining the amount of load on the storage system:
determining relationships between the performance metrics and storage-system load by performing a regression analysis in which the performance metrics serve as independent variables and the storage-system load serves as a dependent variable; and selecting, based on the relationships, the performance metrics from among a group of candidate performance metrics for use in determining the amount of load on the storage system.
20. A non-transitory computer-readable medium comprising program code that is executable by a processor for causing the processor to:
determine an amount of load on a storage system based on values for performance metrics indicating a performance of the storage system; determine that the storage system is to have a target number of replicas of content based on the amount of load on the storage system; and adjust the storage system to have the target number of replicas of the content.
Ref US20210081432: Claims:
1. A method for using lightweight checkpoints in a data storage system, the method comprising:
receiving, at a source data repository, one or more updates to one or more datasets stored within the source data repository; generating, based on the one or more updates to the one or more datasets, metadata describing the one or more updates to one or more datasets stored within the source data repository; and generating, based on the metadata describing the one or more updates to the one or more datasets, a lightweight checkpoint of metadata describing an ordered application of the one or more updates to the one or more datasets.
2. The method of claim 1, further comprising:
sending, from the source data repository to a target data repository and independent from sending the lightweight checkpoint to the target data repository, data corresponding to the lightweight checkpoint.
3. The method of claim 1, wherein an ordered log of metadata includes one or more lightweight checkpoints.
4. The method of claim 3, wherein a quantity of updates described by a given lightweight checkpoint is a configurable data replication setting.
5. The method of claim 3, wherein the configurable data replication setting is target recovery point objective.
6. The method of claim 1, wherein the recovery event is responsive to one or more of: a detected failure, a detected impending failure, or a detected degradation of responsiveness beyond a compliance policy threshold of the source data repository.
7. The method of claim 1, wherein the recovery event is not based on a failure and is based on a promotion event to prepare, for testing on the target data repository, a replica of the stored data at the source data repository.
8. A storage system that includes a computer memory and a computer processor, the computer memory including program instructions that, when executed by the computer processor, cause the storage system to carry out the steps of:
receiving, at a target data repository from a source data repository, metadata describing one or more updates to one or more datasets stored within the source data repository; generating, based on the metadata describing the one or more updates to the one or more datasets, an ordered log of metadata describing an ordered application of the one or more updates to the one or more datasets; and generating, based on the ordered log of metadata, the one or more datasets in accordance with the one or more updates.
9. The storage system of claim 8, wherein the program instructions, when executed by the computer processor, further cause the storage system to carry out the steps of:
receiving, at the target data repository from the source data repository and independent from receiving the metadata describing the one or more updates to the one or more datasets, data corresponding to the one or more updates to the one or more datasets.
10. The storage system of claim 8, wherein the ordered log of metadata includes one or more lightweight checkpoints.
11. The storage system of claim 10, wherein a quantity of updates described by a given lightweight checkpoint on a configurable data replication setting.
12. The storage system of claim 10, wherein a quantity of updates described by a given lightweight checkpoint on a configurable data replication setting.
13. The storage system of claim 10, wherein the configurable data replication setting is target recovery point objective.
14. The storage system of claim 8, wherein the recovery event is responsive to one or more of: a detected failure, a detected impending failure, or a detected degradation of responsiveness beyond a compliance policy threshold of the source data repository.
15. The storage system of claim 8, wherein the recovery event is not based on a failure and is based on a promotion event to prepare, for testing on the target data repository, a replica of the stored data at the source data repository.
16. A method for continuous data protection, the method comprising:
generating, based on the metadata describing the one or more updates to the one or more datasets, an ordered log of metadata describing an ordered application of the one or more updates to the one or more datasets; and generating, on the source data repository and based on the ordered log of metadata, at least a portion of the one or more datasets in accordance with the one or more updates corresponding to a specified point in time.
17. The method of claim 16, wherein stored data to generate the one or more datasets i
[Truncated to input limit]