DETAILED ACTION
This Action is responsive to the Amendments filed on 03/13/2026.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims Status
Claims 1-20 are amended. Claims 1-20 are pending and have been examined.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1, 11, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Cocagne et. al (US 20170131922 A1)(cited by examiner in previous action)(hereafter referred to as Cocagne) further in view of Wang et al. (US 20250068469 A1)(hereafter referred to as Wang).
Regarding Claim 1,
Cocagne discloses the following limitations:
A method for managing a distributed database (DSN 10, Fig. 1 // Fig. 9), the distributed database including a plurality of storage nodes … configured to store data (Memories, Fig. 9 // “one or more physical memory devices” [0046]), the plurality of storage nodes being divided into a plurality of node groups (DST EX units 1-n, Fig. 9 // “The storage set, or DSN memory, may include a set of DST execution (EX) units 1-n, e.g., storage units 36 of FIG. 1. Each DST execution units includes … a plurality of memories 1-M. Each memory may be implemented utilizing the one or more physical memory devices.” [0043]) – As shown in Fig. 9 and taught in ¶0043, storage within the DSN comprises a plurality of DST EX units, each unit comprising a plurality of memory devices. In this context, the collective memories of Fig. 9 (i.e., “a plurality of storage nodes”) are divided into a plurality of DST EX units (i.e., “a plurality of node groups”)--, and
each of the plurality of node groups including at least one storage node and configured to store a … data copy (Fig. 3 // “encoded data slices” [0038]) corresponding to the data (“As a result of encoding, the computing device 12 or 16 produces a plurality of sets of encoded data slices, which are provided with their respective slice names to the storage units for storage” [0038] // ¶¶0033-38) – As shown in Fig. 3, data objects are encoded into “a plurality of sets of encoded data slices” which are distributed across the storage units of the DSN--,
the method comprising:
receiving (Fig. 10, block 576) a data access request for the data stored in the distributed database (“The method includes block 576 where a processing module … determines to access at least some encoded data slices of a set of encoded data slices … For example, the processing unit receives a data access request” [0049]);
determining (Fig. 10, blocks 578 - 582), in response to the data access request, whether a target node group on which an online operation or maintenance task (“necessary maintenance” [0041]) is being executed exists (“whether the slice access is available to an encoded data slice” [0050]) in the plurality of node groups (“For each slice name, the method continues at block 578 where the processing module determines whether the slice access is available to an encoded data slice associated with the slice name based on … a storage resource identifier … at block 580 where the processing module selects a threshold number of encoded data slices for access based on the availability of the set of encoded data slices … at block 582 where the processing module identifies associated storage resources corresponding to the selected threshold number of encoded data slices” [0050-52] // “Referring to FIGS. 9 and 10… some memory devices can benefit from being given occasional “time off”, e.g. no access requests during some time period, in order to perform necessary maintenance … In this way, some embodiments provide for every DSN storage unit and/or memory device to have periods of inactivity, or at least no activity induced from requests originating externally from the DSN storage unit or memory device, on a periodic or round-robin basis.” [0041-42]) – As shown in Fig. 10, during blocks 578-582, for each slice (and thus for each DST EX unit storing a slice) included within the set of encoded data slices, the processing module determines whether or not the encoded data slice is available (578); after which a threshold number of available encoded data slices are selected (580) and corresponding storage resources holding the selected encoded data slices are identified (582). As taught in ¶0041, encoded data slices are not accessible to data access request while underlying storage resources are performing necessary maintenance. Examiner accordingly considers a processing module using a “storage resource identifier” to determine that an encoded data slice (and thus a corresponding DST EX unit) is currently unavailable as reading on the claimed concept of “determining” “a target node group” on which a “maintenance task being executed” because encoded data slices are not available during maintenance. In this context, examiner considers each DST EX unit associated with an encoded data slice which is not currently available as “a target node group”-- ; and
allocating (Fig. 10, block 584) the data access request to a storage node in a node group of the plurality of node groups other than the target node group (“associated storage resources corresponding to the selected threshold number of encoded data slices” [0052]) for execution in response to that the target node group on which the online operation or maintenance task is being executed exists in the plurality of node groups (“The method continues at block 584 where the processing module accesses the identified storage resources using the threshold number of slice names. For example, the processing module generates a threshold number of access requests that includes the threshold number of slice names and sends the generated access requests to the associated storage units” [0053]) – As shown in Fig. 10, associated storage resources which store the selected (and available) encoded data slices (i.e., resources “other than the target node group” which currently store unavailable slices) are accessed during block 584.
Although Cocagne ¶0044 discloses that each DST EX unit of storage set 570 receives at least one encoded slice of a dataset (e.g., memory 1 of each DST EX unit receives an encoded slice), Cocagne is silent regarding how data is distributed across memories within a respective DST EX Unit. Specifically, Cocagne does not explicitly disclose the following limitations:
a plurality of storage nodes each having a processing capacity …
each of the plurality of node groups including at least one storage node and configured to store a complete data copy
However, Wang discloses the following limitations:
a plurality of storage nodes (Fig. 2) each having a processing capacity (¶0074) …
each of the plurality of node groups (“an ES cluster” [0074] // ¶0067) including at least one storage node (Fig. 2) and configured to store a complete data copy (“The ES cluster is a set of a plurality of nodes and can independently provide search services” [0068] // “The data plane of the ES cluster may include a reader cluster and a writer cluster. The reader cluster includes N nodes in total … One of more replicas of an index may be distributed in each node in the reader cluster, and the reader cluster may be used to process a data read request. The write cluster includes M nodes in total … the writer cluster may be used to process a data write request” [0074] // Fig. 2) – As shown in Wang Fig. 2 and as taught in ¶0067, an “ES cluster” comprises plural storage nodes and provides search services for a database, similar to how an individual DST Ex Unit of Cocagne Fig. 9 comprises plural memories 1-M and performs access requests for a distributed database. Examiner accordingly considers the ES cluster depicted in Wang Fig. 2 as analogous to a DST EX Unit of Cocagne Fig. 9 (i.e., a “node group”), whereby the reader and writer cluster nodes of Wang correspond to the memories 1-M of a DST EX Unit of Cocagne. As taught in Wang ¶0074, “one or more replicas of an index” (i.e., “a complete data copy”) is distributed to each reader cluster node of the ES cluster (i.e., each “node group” comprises at least N reader cluster nodes, each of which at least store one replica).
Cocagne and Wang are considered analogous to the claimed invention because they all relate to the same field of selective allocation of memory access requests to nodes of a distributed database. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne with the teachings of Wang and realize a method of storing a complete data copy in each node group of a distributed database. Doing so enables read/write separation to be performed in a distributed database by enabling nodes of a reader cluster to respond to read requests for an entire index while nodes of a writer cluster respond to write requests for particular shards of the index, effectively improving read and write efficiency, as taught in Wang ¶0074: “when data needs to be written into an index, the data may be written to only a shard distributed in a writer cluster, and the shard in the writer cluster synchronizes the data to one or more replicas in a reader cluster. When data is read (data is queried) from an index, the data may be read only from a replica distributed in a reader cluster. In this way, data read/write splitting can be implemented. This effectively improves data read/write efficiency.” [0074]
Regarding Claim 11,
Cocagne discloses the following limitations:
An electronic device (Fig. 1), comprising
one or more processors (“processing module” [0057]), one or more storage devices (“a plurality of memory devices” [0057]), and computer executable instructions (“corresponding operational instructions” [0057]) stored in the one or more storage devices, the computer executable instructions when executed by the one or more processors, enabling the one or more processors to, individually or collectively, conduct actions including (¶0057):
receiving (Fig. 10, block 576) a data access request for data stored in a distributed database (DSN 10, Fig. 1 // Fig. 9)(“The method includes block 576 where a processing module … determines to access at least some encoded data slices of a set of encoded data slices … For example, the processing unit receives a data access request” [0049]),
the distributed database including a plurality of storage nodes … configured to store data (Memories, Fig. 9 // “one or more physical memory devices” [0046]), the plurality of storage nodes being divided into a plurality of node groups (DST EX units 1-n, Fig. 9 // “The storage set, or DSN memory, may include a set of DST execution (EX) units 1-n, e.g., storage units 36 of FIG. 1. Each DST execution units includes … a plurality of memories 1-M. Each memory may be implemented utilizing the one or more physical memory devices.” [0043]) – As shown in Fig. 9 and taught in ¶0043, storage within the DSN comprises a plurality of DST EX units, each unit comprising a plurality of memory devices. In this context, the collective memories of Fig. 9 (i.e., “a plurality of storage nodes”) are divided into a plurality of DST EX units (i.e., “a plurality of node groups”)--, and
each of the plurality of node groups including at least one storage node and configured to store a … data copy (Fig. 3 // “encoded data slices” [0038]) corresponding to the data (“As a result of encoding, the computing device 12 or 16 produces a plurality of sets of encoded data slices, which are provided with their respective slice names to the storage units for storage” [0038] // ¶¶0033-38) – As shown in Fig. 3, data objects are encoded into “a plurality of sets of encoded data slices” which are distributed across the storage units of the DSN--,
determining (Fig. 10, blocks 578 - 582), in response to the data access request, whether a target node group on which an online operation or maintenance task (“necessary maintenance” [0041]) is being executed exists (“whether the slice access is available to an encoded data slice” [0050]) in the plurality of node groups (“For each slice name, the method continues at block 578 where the processing module determines whether the slice access is available to an encoded data slice associated with the slice name based on … a storage resource identifier … at block 580 where the processing module selects a threshold number of encoded data slices for access based on the availability of the set of encoded data slices … at block 582 where the processing module identifies associated storage resources corresponding to the selected threshold number of encoded data slices” [0050-52] // “Referring to FIGS. 9 and 10… some memory devices can benefit from being given occasional “time off”, e.g. no access requests during some time period, in order to perform necessary maintenance … In this way, some embodiments provide for every DSN storage unit and/or memory device to have periods of inactivity, or at least no activity induced from requests originating externally from the DSN storage unit or memory device, on a periodic or round-robin basis.” [0041-42]) – As shown in Fig. 10, during blocks 578-582, for each slice (and thus for each DST EX unit storing a slice) included within the set of encoded data slices, the processing module determines whether or not the encoded data slice is available (578); after which a threshold number of available encoded data slices are selected (580) and corresponding storage resources holding the selected encoded data slices are identified (582). As taught in ¶0041, encoded data slices are not accessible to data access request while underlying storage resources are performing necessary maintenance. Examiner accordingly considers a processing module using a “storage resource identifier” to determine that an encoded data slice (and thus a corresponding DST EX unit) is currently unavailable as reading on the claimed concept of “determining” “a target node group” on which a “maintenance task being executed” because encoded data slices are not available during maintenance. In this context, examiner considers each DST EX unit associated with an encoded data slice which is not currently available as “a target node group”--; and
allocating (Fig. 10, block 584) the data access request to a storage node in a node group of the plurality of node groups other than the target node group (“associated storage resources corresponding to the selected threshold number of encoded data slices” [0052]) for execution in response to that the target node group on which the online operation or maintenance task is being executed exists in the plurality of node groups (“The method continues at block 584 where the processing module accesses the identified storage resources using the threshold number of slice names. For example, the processing module generates a threshold number of access requests that includes the threshold number of slice names and sends the generated access requests to the associated storage units” [0053]) – As shown in Fig. 10, associated storage resources which store the selected (and available) encoded data slices (i.e., resources “other than the target node group” which currently store unavailable slices) are accessed during block 584.
Although Cocagne ¶0044 discloses that each DST EX unit of storage set 570 receives at least one encoded slice of a dataset (e.g., memory 1 of each DST EX unit receives an encoded slice), Cocagne is silent regarding how data is distributed across memories within a respective DST EX Unit. Specifically, Cocagne does not explicitly disclose the following limitations:
a plurality of storage nodes each having a processing capacity …
each of the plurality of node groups including at least one storage node and configured to store a complete data copy
However, Wang discloses the following limitations:
a plurality of storage nodes (Fig. 2) each having a processing capacity (¶0074) …
each of the plurality of node groups (“an ES cluster” [0074] // ¶0067) including at least one storage node (Fig. 2) and configured to store a complete data copy (“The ES cluster is a set of a plurality of nodes and can independently provide search services” [0068] // “The data plane of the ES cluster may include a reader cluster and a writer cluster. The reader cluster includes N nodes in total … One of more replicas of an index may be distributed in each node in the reader cluster, and the reader cluster may be used to process a data read request. The write cluster includes M nodes in total … the writer cluster may be used to process a data write request” [0074] // Fig. 2) – As shown in Wang Fig. 2 and as taught in ¶0067, an “ES cluster” comprises plural storage nodes and provides search services for a database, similar to how an individual DST Ex Unit of Cocagne Fig. 9 comprises plural memories 1-M and performs access requests for a distributed database. Examiner accordingly considers the ES cluster depicted in Wang Fig. 2 as analogous to a DST EX Unit of Cocagne Fig. 9 (i.e., a “node group”), whereby the reader and writer cluster nodes of Wang correspond to the memories 1-M of a DST EX Unit of Cocagne. As taught in Wang ¶0074, “one or more replicas of an index” (i.e., “a complete data copy”) is distributed to each reader cluster node of the ES cluster (i.e., each “node group” comprises at least N reader cluster nodes, each of which at least store one replica).
Cocagne and Wang are considered analogous to the claimed invention because they all relate to the same field of selective allocation of memory access requests to nodes of a distributed database. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne with the teachings of Wang and realize a method of storing a complete data copy in each node group of a distributed database. Doing so enables read/write separation to be performed in a distributed database by enabling nodes of a reader cluster to respond to read requests for an entire index while nodes of a writer cluster respond to write requests for particular shards of the index, effectively improving read and write efficiency, as taught in Wang ¶0074: “when data needs to be written into an index, the data may be written to only a shard distributed in a writer cluster, and the shard in the writer cluster synchronizes the data to one or more replicas in a reader cluster. When data is read (data is queried) from an index, the data may be read only from a replica distributed in a reader cluster. In this way, data read/write splitting can be implemented. This effectively improves data read/write efficiency.” [0074]
Regarding Claim 20,
Cocagne discloses the following limitations:
A computer storage medium (“a plurality of memory devices” [0057]), wherein the computer storage medium stores a computer program (“corresponding operational instructions” [0057]), the computer program, when executed by one or more processors (“processing module” [0057]), enabling the one or more processors to, individually or collectively, to implement actions including (¶0057):
receiving (Fig. 10, block 576) a data access request for data stored in a distributed database (DSN 10, Fig. 1 // Fig. 9)(“The method includes block 576 where a processing module … determines to access at least some encoded data slices of a set of encoded data slices … For example, the processing unit receives a data access request” [0049]),
the distributed database including a plurality of storage nodes … configured to store data (Memories, Fig. 9 // “one or more physical memory devices” [0046]), the plurality of storage nodes being divided into a plurality of node groups (DST EX units 1-n, Fig. 9 // “The storage set, or DSN memory, may include a set of DST execution (EX) units 1-n, e.g., storage units 36 of FIG. 1. Each DST execution units includes … a plurality of memories 1-M. Each memory may be implemented utilizing the one or more physical memory devices.” [0043]) – As shown in Fig. 9 and taught in ¶0043, storage within the DSN comprises a plurality of DST EX units, each unit comprising a plurality of memory devices. In this context, the collective memories of Fig. 9 (i.e., “a plurality of storage nodes”) are divided into a plurality of DST EX units (i.e., “a plurality of node groups”)--, and
each of the plurality of node groups including at least one storage node and configured to store a … data copy (Fig. 3 // “encoded data slices” [0038]) corresponding to the data (“As a result of encoding, the computing device 12 or 16 produces a plurality of sets of encoded data slices, which are provided with their respective slice names to the storage units for storage” [0038] // ¶¶0033-38) – As shown in Fig. 3, data objects are encoded into “a plurality of sets of encoded data slices” which are distributed across the storage units of the DSN--,
determining (Fig. 10, blocks 578 - 582), in response to the data access request, whether a target node group on which an online operation or maintenance task (“necessary maintenance” [0041]) is being executed exists (“whether the slice access is available to an encoded data slice” [0050]) in the plurality of node groups (“For each slice name, the method continues at block 578 where the processing module determines whether the slice access is available to an encoded data slice associated with the slice name based on … a storage resource identifier … at block 580 where the processing module selects a threshold number of encoded data slices for access based on the availability of the set of encoded data slices … at block 582 where the processing module identifies associated storage resources corresponding to the selected threshold number of encoded data slices” [0050-52] // “Referring to FIGS. 9 and 10… some memory devices can benefit from being given occasional “time off”, e.g. no access requests during some time period, in order to perform necessary maintenance … In this way, some embodiments provide for every DSN storage unit and/or memory device to have periods of inactivity, or at least no activity induced from requests originating externally from the DSN storage unit or memory device, on a periodic or round-robin basis.” [0041-42]) – As shown in Fig. 10, during blocks 578-582, for each slice (and thus for each DST EX unit storing a slice) included within the set of encoded data slices, the processing module determines whether or not the encoded data slice is available (578); after which a threshold number of available encoded data slices are selected (580) and corresponding storage resources holding the selected encoded data slices are identified (582). As taught in ¶0041, encoded data slices are not accessible to data access request while underlying storage resources are performing necessary maintenance. Examiner accordingly considers a processing module using a “storage resource identifier” to determine that an encoded data slice (and thus a corresponding DST EX unit) is currently unavailable as reading on the claimed concept of “determining” “a target node group” on which a “maintenance task being executed” because encoded data slices are not available during maintenance. In this context, examiner considers each DST EX unit associated with an encoded data slice which is not currently available as “a target node group”--; and
allocating (Fig. 10, block 584) the data access request to a storage node in a node group of the plurality of node groups other than the target node group (“associated storage resources corresponding to the selected threshold number of encoded data slices” [0052]) for execution in response to that the target node group on which the online operation or maintenance task is being executed exists in the plurality of node groups (“The method continues at block 584 where the processing module accesses the identified storage resources using the threshold number of slice names. For example, the processing module generates a threshold number of access requests that includes the threshold number of slice names and sends the generated access requests to the associated storage units” [0053]) – As shown in Fig. 10, associated storage resources which store the selected (and available) encoded data slices (i.e., resources “other than the target node group” which currently store unavailable slices) are accessed during block 584.
Although Cocagne ¶0044 discloses that each DST EX unit of storage set 570 receives at least one encoded slice of a dataset (e.g., memory 1 of each DST EX unit receives an encoded slice), Cocagne is silent regarding how data is distributed across memories within a respective DST EX Unit. Specifically, Cocagne does not explicitly disclose the following limitations:
a plurality of storage nodes each having a processing capacity …
each of the plurality of node groups including at least one storage node and configured to store a complete data copy
However, Wang discloses the following limitations:
a plurality of storage nodes (Fig. 2) each having a processing capacity (¶0074) …
each of the plurality of node groups (“an ES cluster” [0074] // ¶0067) including at least one storage node (Fig. 2) and configured to store a complete data copy (“The ES cluster is a set of a plurality of nodes and can independently provide search services” [0068] // “The data plane of the ES cluster may include a reader cluster and a writer cluster. The reader cluster includes N nodes in total … One of more replicas of an index may be distributed in each node in the reader cluster, and the reader cluster may be used to process a data read request. The write cluster includes M nodes in total … the writer cluster may be used to process a data write request” [0074] // Fig. 2) – As shown in Wang Fig. 2 and as taught in ¶0067, an “ES cluster” comprises plural storage nodes and provides search services for a database, similar to how an individual DST Ex Unit of Cocagne Fig. 9 comprises plural memories 1-M and performs access requests for a distributed database. Examiner accordingly considers the ES cluster depicted in Wang Fig. 2 as analogous to a DST EX Unit of Cocagne Fig. 9 (i.e., a “node group”), whereby the reader and writer cluster nodes of Wang correspond to the memories 1-M of a DST EX Unit of Cocagne. As taught in Wang ¶0074, “one or more replicas of an index” (i.e., “a complete data copy”) is distributed to each reader cluster node of the ES cluster (i.e., each “node group” comprises at least N reader cluster nodes, each of which at least store one replica).
Cocagne and Wang are considered analogous to the claimed invention because they all relate to the same field of selective allocation of memory access requests to nodes of a distributed database. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne with the teachings of Wang and realize a method of storing a complete data copy in each node group of a distributed database. Doing so enables read/write separation to be performed in a distributed database by enabling nodes of a reader cluster to respond to read requests for an entire index while nodes of a writer cluster respond to write requests for particular shards of the index, effectively improving read and write efficiency, as taught in Wang ¶0074: “when data needs to be written into an index, the data may be written to only a shard distributed in a writer cluster, and the shard in the writer cluster synchronizes the data to one or more replicas in a reader cluster. When data is read (data is queried) from an index, the data may be read only from a replica distributed in a reader cluster. In this way, data read/write splitting can be implemented. This effectively improves data read/write efficiency.” [0074]
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Cocagne further in view of Wang and Reed et al. (US 20220291850 A1)(cited by examiner in previous action)(hereafter referred to as Reed).
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Cocagne and Wang discloses the following limitations:
The method according to claim 1 (see Claim 1 limitation mappings above),
Although Cocagne ¶0029 generally discloses that maintenance operations can include “replacing” and “expanding” units of the DSN, Cocagne and Wang do not explicitly disclose the following limitations:
wherein the online operation or maintenance task includes an online capacity expansion task or an online capacity reduction task, the online capacity expansion task adds a storage node to a node group, and the online capacity reduction task removes a storage node from a node group.
However, Reed discloses the following limitations:
the online operation or maintenance task (“preventative maintenance” [0213]) includes an online capacity expansion task (“adding a node” [0220]) or an online capacity reduction task (“removing a node” [0218]), the online capacity expansion task adds a storage node to a node group, and the online capacity reduction task removes a storage node from a node group (“As one example of a preventative maintenance program, swapping of server nodes may be scheduled” [0213] // “removing a logical node includes relocating all logical modules elsewhere and evacuating all virtual resources from the logical node being removed … adding a logical node includes relocating logical modules to include components on the new node as needed” [0218-220]) – As taught in Reed, as part of preventative maintenance operations, nodes can be added or removed from a cluster.
Cocagne, Wang, and Reed are considered analogous to the claimed invention because they all relate to the same field of performing maintenance on nodes in a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne and Wang with the teachings of Reed and realize a method of performing maintenance by adding or removing nodes from a node group. Doing so improves system reliability, as disclosed in Reed ¶0212: “In some embodiments, using the reconfiguration mechanism described herein, preventative maintenance programs may also be established to improve system reliability.”
Regarding Claim 12,
The same motivation to combine provided in Claim 11 is equally applicable to Claim 12. The combined teachings of Cocagne and Wang discloses the following limitations:
The electronic device according to claim 11 (see Claim 11 limitation mappings above),
Although Cocagne ¶0029 generally discloses that maintenance operations can include “replacing” and “expanding” units of the DSN, Cocagne does not explicitly disclose the following limitations:
wherein the online operation or maintenance task includes an online capacity expansion task or an online capacity reduction task, the online capacity expansion task adds a storage node to a node group, and the online capacity reduction task removes a storage node from a node group.
However, Reed discloses the following limitations:
the online operation or maintenance task (“preventative maintenance” [0213]) includes an online capacity expansion task (“adding a node” [0220]) or an online capacity reduction task (“removing a node” [0218]), the online capacity expansion task adds a storage node to a node group, and the online capacity reduction task removes a storage node from a node group (“As one example of a preventative maintenance program, swapping of server nodes may be scheduled” [0213] // “removing a logical node includes relocating all logical modules elsewhere and evacuating all virtual resources from the logical node being removed … adding a logical node includes relocating logical modules to include components on the new node as needed” [0218-220]) – As taught in Reed, as part of preventative maintenance operations, nodes can be added or removed from a cluster.
Cocagne, Wang, and Reed are considered analogous to the claimed invention because they all relate to the same field of performing maintenance on nodes in a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne and Wang with the teachings of Reed and realize a method of performing maintenance by adding or removing nodes from a node group. Doing so improves system reliability, as disclosed in Reed ¶0212: “In some embodiments, using the reconfiguration mechanism described herein, preventative maintenance programs may also be established to improve system reliability.”
Claims 3-5 and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Cocagne further in view of Wang and Algie et al. (US 20220108033 A1)(cited by examiner in previous action)(hereafter referred to as Algie).
Regarding Claim 3,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 3. The combined teachings of Cocagne and Wang discloses the following limitations:
The method according to claim 1 (see Claim 1 limitation mappings above),
Although Cocagne ¶¶0041-42 generally discloses a scheduling process of internal maintenance operations, Cocagne and Wang do not explicitly disclose the following limitations:
further comprising: delivering the online operation or maintenance task to one of the plurality of node groups in response to a received instruction for executing an online operation or maintenance operation on the node group.
However, Algie discloses the following limitations:
delivering the online operation or maintenance task (“urgent read requests” [0298]) to one of the plurality of node groups (“DST execution units” [0298]) in response to a received instruction (“error messages” [0296]) for executing an online operation or maintenance operation (“a data salvaging process” [0298]) on the node group (“The DSN functions to select a data integrity maintenance process for maintaining integrity of stored data within the DST execution unit pool … the DST client module 34 receives error messages indicating that memories 1-2 and 2-2 are failing … the DST process client module 34 initiates a data salvaging processes to recover encoded data slices from the set of encoded data slices … For example, the DST client module 34 issues, via the network 24, urgent read slice requests 480 for the encoded data slices to be recovered to the DST execution units corresponding to the failing memory devices.” [0295-298]) – Examiner considers the DST execution units depicted in Algie Fig. 1 as analogous to the DST execution units of Cocagne Fig. 1. As taught in Algie, in order to perform “a data salvaging process” to recover encoded data slices (i.e., a “maintenance operation”), a DST client module receives “error messages” concerning particular failing memories (i.e., “a received instruction”) and subsequently delivers “urgent read slice requests” (i.e., “maintenance task[s]”) to the corresponding DST execution units having the failing memories.
Cocagne and Algie are considered analogous to the claimed invention because they all relate to the same field of scheduling both data access and maintenance tasks in a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne with the teachings of Algie and realize a method of performing a maintenance operation on a target node group by delivering a task to the target node group. Doing so improves the reliability of a distributed database by enabling quick recovery of encoded data slices from identified failing memories, as disclosed in Algie ¶0298: “For instance, the DST client module 34 issues, via the network 24, the urgent read slice requests 480 to DST execution units 1 and 2 to quickly recover recoverable encoded data slices from the memories 1-2, and 2-2.” [0298].
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Cocagne and Wang discloses the following limitations:
The method according to claim 1 (see Claim 1 limitation mappings above),
Although Cocagne ¶¶0050-51 generally disclose that an “availability indicator” can be used to select the threshold number of encoded data slices to access, Cocagne does not disclose how encoded data slices are selected. Specifically, Cocagne and Wang do not explicitly disclose the following limitations:
wherein a traffic weight is configured for a node group of the plurality of node groups, and the traffic weight is positively correlated with a number of data access requests allocated to the node group; the method further comprises:
setting the traffic weight of the node group of the plurality of node groups to 0 in response to a received instruction for executing an online operation or maintenance task on the node group; and
the allocating the data access request to the storage node in the node group other than the target node group includes: allocating the data access request to a node group having a traffic weight that is not 0.
However, Algie discloses the following limitations:
wherein a traffic weight (“a weighting level” [0277]) is configured for a node group of the plurality of node groups, and the traffic weight is positively correlated with a number of data access requests allocated to the node group (“For each available DST execution unit pool, the DST client module 34 updates a weighting level based on available storage capacity … the DST client module 34 increases the weighting when the capacities are more favorable for further storage of data” [0277]) -- Examiner considers the DST execution units depicted in Algie Fig. 1 as analogous to the DST execution units of Cocagne Fig. 1. As taught in Algie ¶0277, each DST execution unit is assigned “a weighting level” indicative of “available storage capacity”, whereby a weighting level is increased when a given unit is expected to be favorable to additional data storage tasks (i.e., “positively correlated” to an amount of future data writing requests capable of being performed); the method further comprises:
setting the traffic weight of the node group of the plurality of node groups to 0 (“de-prioritizing priority levels of execution of data access tasks” [03007]) in response to a received instruction for executing an online operation or maintenance task on the node group (“Having determined the probability of potential future data loss, the DST client module 34 … facilitates execution of a preventative data loss migration process … temporarily de-prioritizing priority execution levels of execution of data access tasks” [0307]) – As taught in Algie ¶0307, after a preventative data loss migration process is executed (i.e., “executing” a “maintenance task”), a corresponding priority execution level for data access tasks is “de-prioritized”. In this context, examiner considers de-prioritizing a priority level for a DST execution unit as reading on the claimed concept of “setting the traffic weight” “to 0” (i.e., setting a priority level to a de-prioritized state); and
the allocating the data access request to the storage node in the node group other than the target node group includes: allocating (Fig. 40D, block 402) the data access request to a node group having a traffic weight that is not 0 (“the processing module selects a plurality of resource levels associated with the DSN memory. The selection may be based on one or more of … a range of weights associated with available resources … the method continues at step 402 where the processing module selects one or more resources associated with the resource level based on the ranked scoring information … For example, the processing module selects a plurality of resources associated with highest scores when a plurality of resources are required.” [0271] // Fig. 40D // ¶¶0269-273) – As shown in Fig. 40D and detailed in ¶¶0269-273, DST execution units “associated with highest scores” (whereby scores are based on “a range of weights”; see ¶0270) are selected (block 402) to perform a data access request (received during block 394). In this context, examiner considers selecting execution units “associated with highest scores” (i.e., associated with the highest priority levels) for performing a data access request as reading on the claimed concept allocating a data access request to a DST execution unit having a priority level which is not de-prioritized (i.e., “having a traffic weight” which is not in a de-prioritized state; i.e., having a traffic weight “that is not 0”).
Cocagne, Wang, and Algie are considered analogous to the claimed invention because they all relate to the same field of scheduling both data access and maintenance tasks in a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne and Wang with the teachings of Algie and realize a method of performing a maintenance operation on a target node group by delivering a task to the target node group. Doing so improves the reliability of a distributed database by enabling quick recovery of encoded data slices from identified failing memories, as disclosed in Algie ¶0298: “For instance, the DST client module 34 issues, via the network 24, the urgent read slice requests 480 to DST execution units 1 and 2 to quickly recover recoverable encoded data slices from the memories 1-2, and 2-2.” [0298].
Regarding Claim 5,
The same motivation to combine provided in Claim 4 is equally applicable to Claim 5. The combined teachings of Cocagne, Wang, and Algie disclose the following limitations:
The method according to claim 4, further comprising: after the online operation or maintenance task is completed for the target node group, determining a performance indicator (Cocagne, “availability indicator” [0045] // ¶0042) of a storage node included in the target node group (Cocagne, “produce an availability indicator” [0045]), and updating the traffic weight of the target node group based on the performance indicator (Algie, “increases the weighting when the capacities are more favorable for further storage of data” [0277]), wherein the performance indicator indicates a capability of processing the data access request by the storage node included in the target node group (Cocagne, “The determining includes … applying the deterministic function to the slice name, the storage resource identifier, and the current time to produce an availability indicator (e.g., available, not available) … the DS client module 34 determines that all encoded data slices .. are currently available for access” [0045]) – As taught in Cocagne ¶0045, an “availability indicator” (i.e., “a performance indicator” associated with each slice for each DST EX unit) is calculated using a time-based deterministic function which accounts for scheduled down-time for maintenance (see Cocagne ¶0042). As taught in Algie ¶0277, DST execution unit weighting levels (i.e., ‘the traffic weight”) are increased based on favorable conditions for further data storage (e.g., such as indicated by an “availability indicator” of Cocagne). Finally, as taught in Cocagne, the availability indicator signals which DST EX units are “currently available for access” (i.e., “indicates a capability” of processing a current request).
Regarding Claim 13,
The same motivation to combine provided in Claim 11 is equally applicable to Claim 13. The combined teachings of Cocagne and Wang discloses the following limitations:
The electronic device according to claim 11 (see Claim 11 limitation mappings above),
Although Cocagne ¶¶0041-42 generally discloses a scheduling process of internal maintenance operations, Cocagne and Wang do not explicitly disclose the following limitations:
wherein the actions further include: delivering the online operation or maintenance task to one of the plurality of node groups in response to a received instruction for executing an online operation or maintenance operation on the node group.
However, Algie discloses the following limitations:
delivering the online operation or maintenance task (“urgent read requests” [0298]) to one of the plurality of node groups (“DST execution units” [0298]) in response to a received instruction (“error messages” [0296]) for executing an online operation or maintenance operation (“a data salvaging process” [0298]) on the node group (“The DSN functions to select a data integrity maintenance process for maintaining integrity of stored data within the DST execution unit pool … the DST client module 34 receives error messages indicating that memories 1-2 and 2-2 are failing … the DST process client module 34 initiates a data salvaging processes to recover encoded data slices from the set of encoded data slices … For example, the DST client module 34 issues, via the network 24, urgent read slice requests 480 for the encoded data slices to be recovered to the DST execution units corresponding to the failing memory devices.” [0295-298]) – Examiner considers the DST execution units depicted in Algie Fig. 1 as analogous to the DST execution units of Cocagne Fig. 1. As taught in Algie, in order to perform “a data salvaging process” to recover encoded data slices (i.e., a “maintenance operation”), a DST client module receives “error messages” concerning particular failing memories (i.e., “a received instruction”) and subsequently delivers “urgent read slice requests” (i.e., “maintenance task[s]”) to the corresponding DST execution units having the failing memories.
Cocagne, Wang, and Algie are considered analogous to the claimed invention because they all relate to the same field of scheduling both data access and maintenance tasks in a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne and Wang with the teachings of Algie and realize a method of performing a maintenance operation on a target node group by delivering a task to the target node group. Doing so improves the reliability of a distributed database by enabling quick recovery of encoded data slices from identified failing memories, as disclosed in Algie ¶0298: “For instance, the DST client module 34 issues, via the network 24, the urgent read slice requests 480 to DST execution units 1 and 2 to quickly recover recoverable encoded data slices from the memories 1-2, and 2-2.” [0298].
Regarding Claim 14,
The same motivation to combine provided in Claim 11 is equally applicable to Claim 14. The combined teachings of Cocagne and Wang discloses the following limitations:
The electronic device according to claim 11 (see Claim 11 limitation mappings above),
Although Cocagne ¶¶0050-51 generally disclose that an “availability indicator” can be used to select the threshold number of encoded data slices to access, Cocagne does not disclose how encoded data slices are selected. Specifically, Cocagne and Wang do not explicitly disclose the following limitations:
wherein a traffic weight is configured for a node group of the plurality of node groups, and the traffic weight is positively correlated with a number of data access requests allocated to the node group; the actions further include:
setting the traffic weight of the node group of the plurality of node groups to 0 in response to a received instruction for executing an online operation or maintenance task on the node group; and
the allocating the data access request to the storage node in the node group other than the target node group includes: allocating the data access request to a node group having a traffic weight that is not 0.
However, Algie discloses the following limitations:
wherein a traffic weight (“a weighting level” [0277]) is configured for a node group of the plurality of node groups, and the traffic weight is positively correlated with a number of data access requests allocated to the node group (“For each available DST execution unit pool, the DST client module 34 updates a weighting level based on available storage capacity … the DST client module 34 increases the weighting when the capacities are more favorable for further storage of data” [0277]) -- Examiner considers the DST execution units depicted in Algie Fig. 1 as analogous to the DST execution units of Cocagne Fig. 1. As taught in Algie ¶0277, each DST execution unit is assigned “a weighting level” indicative of “available storage capacity”, whereby a weighting level is increased when a given unit is expected to be favorable to additional data storage tasks (i.e., “positively correlated” to an amount of future data writing requests capable of being performed); the actions further include:
setting the traffic weight of the node group of the plurality of node groups to 0 (“de-prioritizing priority levels of execution of data access tasks” [03007]) in response to a received instruction for executing an online operation or maintenance task on the node group (“Having determined the probability of potential future data loss, the DST client module 34 … facilitates execution of a preventative data loss migration process … temporarily de-prioritizing priority execution levels of execution of data access tasks” [0307]) – As taught in Algie ¶0307, after a preventative data loss migration process is executed (i.e., “executing” a “maintenance task”), a corresponding priority execution level for data access tasks is “de-prioritized”. In this context, examiner considers de-prioritizing a priority level for a DST execution unit as reading on the claimed concept of “setting the traffic weight” “to 0” (i.e., setting a priority level to a de-prioritized state); and
the allocating the data access request to the storage node in the node group other than the target node group includes: allocating (Fig. 40D, block 402) the data access request to a node group having a traffic weight that is not 0 (“the processing module selects a plurality of resource levels associated with the DSN memory. The selection may be based on one or more of … a range of weights associated with available resources … the method continues at step 402 where the processing module selects one or more resources associated with the resource level based on the ranked scoring information … For example, the processing module selects a plurality of resources associated with highest scores when a plurality of resources are required.” [0271] // Fig. 40D // ¶¶0269-273) – As shown in Fig. 40D and detailed in ¶¶0269-273, DST execution units “associated with highest scores” (whereby scores are based on “a range of weights”; see ¶0270) are selected (block 402) to perform a data access request (received during block 394). In this context, examiner considers selecting execution units “associated with highest scores” (i.e., associated with the highest priority levels) for performing a data access request as reading on the claimed concept allocating a data access request to a DST execution unit having a priority level which is not de-prioritized (i.e., “having a traffic weight” which is not in a de-prioritized state; i.e., having a traffic weight “that is not 0”).
Cocagne, Wang, and Algie are considered analogous to the claimed invention because they all relate to the same field of scheduling both data access and maintenance tasks in a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne and Wang with the teachings of Algie and realize a method of performing a maintenance operation on a target node group by delivering a task to the target node group. Doing so improves the reliability of a distributed database by enabling quick recovery of encoded data slices from identified failing memories, as disclosed in Algie ¶0298: “For instance, the DST client module 34 issues, via the network 24, the urgent read slice requests 480 to DST execution units 1 and 2 to quickly recover recoverable encoded data slices from the memories 1-2, and 2-2.” [0298].
Regarding Claim 15,
The same motivation to combine provided in Claim 14 is equally applicable to Claim 15. The combined teachings of Cocagne, Wang, and Algie disclose the following limitations:
The electronic device according to claim 1 4 (see Claim 14 limitation mappings above), further comprising: after the online operation or maintenance task is completed for the target node group, determining a performance indicator (Cocagne, “availability indicator” [0045] // ¶0042) of a storage node included in the target node group (Cocagne, “produce an availability indicator” [0045]), and updating the traffic weight of the target node group based on the performance indicator (Algie, “increases the weighting when the capacities are more favorable for further storage of data” [0277]), wherein the performance indicator indicates a capability of processing the data access request by the storage node included in the target node group (Cocagne, “The determining includes … applying the deterministic function to the slice name, the storage resource identifier, and the current time to produce an availability indicator (e.g., available, not available) … the DS client module 34 determines that all encoded data slices .. are currently available for access” [0045]) – As taught in Cocagne ¶0045, an “availability indicator” (i.e., “a performance indicator” associated with each slice for each DST EX unit) is calculated using a time-based deterministic function which accounts for scheduled down-time for maintenance (see Cocagne ¶0042). As taught in Algie ¶0277, DST execution unit weighting levels (i.e., ‘the traffic weight”) are increased based on favorable conditions for further data storage (e.g., such as indicated by an “availability indicator” of Cocagne). Finally, as taught in Cocagne, the availability indicator signals which DST EX units are “currently available for access” (i.e., “indicates a capability” of processing a current request).
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Cocagne further in view of Wang and Jujjuri et al. (US 20190042638 A1)(cited by examiner in previous action)(hereafter referred to as Jujjuri).
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Cocagne and Wang discloses the following limitations:
The method according to claim 1 (see Claim 1 limitation mappings above), wherein … the data access request includes a data writing request (“a write operation” [0046]); and
the method further comprises: determining (Fig. 10, block 580) whether the data access request is the data writing request (“the DS client module 34 determines the threshold number (e.g., a write threshold for a write operation, a read threshold for a read operation) and chooses the determined threshold number of encoded data slices for access” [0046]) – As taught in ¶0046, in order to select a number of encoded data slices to access for a write operation, a client module first determines a threshold corresponding to the type of data access request. One of ordinary skill in the art would accordingly understand that the data access request (received during block 576) is at least understood to be a write operation by block 580--;
in response to that the data access request is the data writing request, allocating the data writing request to a storage node (Fig. 10, block 584) – As previously discussed, during block 584, identified storage resources holding the selected encoded data slices are accessed.
Cocagne is silent regarding “primary” and “secondary” types of node groups. Specifically, Cocagne and Wang do not appear to explicitly disclose the following limitations:
the plurality of node groups include a primary node group and a secondary node group …
allocating the data writing request to a storage node in the primary node group, for the storage node in the primary node group to perform a data writing operation corresponding to the data writing request; and
after the storage node in the primary node group performs the data writing operation, sending a data synchronization instruction to a storage node in the secondary node group, to trigger the storage node in the secondary node group to perform data synchronization with the storage node in the primary node group.
However, Jujjuri discloses the following limitations:
the plurality of node groups (Fig. 1) include a primary node group (“Active”, Fig. 1) and a secondary (“Standby”, Fig. 1) node group (“Database system 10, in various embodiments, is implemented via nodes 130 and 140, which are configured to operate as a database cluster and process transaction requests … In various embodiments, database system 10 implements a high availability (HA) service using an active/standby topology in which one or more nodes are elected for writing data to distributed storage 110 on behalf of other nodes – shown as active node 130” [0019]) – As shown in Jujjuri Fig. 1, a plurality of nodes 130 and 140 perform data access requests directed to a distributed database 10, similar to how a plurality of DST EX units of Cocagne Fig. 9 perform data access requests directed to a distributed storage network. Examiner accordingly considers the groups of nodes depicted in Jujjuri Fig. 1 as analogous to the DST EX units of Cocagne Fig. 9. As shown in Jujjuri Fig. 1 and detailed in ¶0019, database nodes are grouped into “active” nodes (i.e., “a primary node group”) and “standby” nodes (i.e., “a secondary node group”)--…
allocating the data writing request to a storage node in the primary node group, for the storage node in the primary node group to perform a data writing operation corresponding to the data writing request (“Active node 130, in various embodiments, is configured to service requests to read and write data to distributed storage 10. Accordingly, active node 130 may receive, from a client device, a write transaction request 131 that causes node 130 to write a set of data to storage 110.” [0023] // Fig. 6, step 620 // “Method 600 begins in step 610 with an active node (e.g., node 130) receiving a request (e.g., request 131) to perform a transaction … in step 620, the active node commits the data to the distributed storage” [0044]) – As taught in Jujjuri, nodes within the “active” type of group perform write transactions to distributed storage--; and
after the storage node in the primary node group performs the data writing operation, sending a data synchronization instruction (“a notification” [0045]) to a storage node in the secondary node group (“a standby node” [0045]), to trigger the storage node in the secondary node group to perform data synchronization (“synchronize a current state of the database system” [0043]) with the storage node in the primary node group (“Method 600 is one embodiment of a method performed … to synchronize a current state of the database system among a plurality of nodes (e.g., nodes 130 and 140) … the active node commits the data to the distributed storage to update the state of the database system and causes the storing of metadata providing an indication (e.g., record 115) of the commitment in a transaction log … In some embodiment, a standby node receives a notification that the transaction log has been modified … In response to receiving the notification, in some embodiments, the standby node updates metadata (e.g., cache 420 and metadata 430) maintained at the standby node for servicing client requests (e.g., request 141)” [0043-45] // Fig. 6) – As shown in Fig. 6 and taught in ¶¶0043-45, after a primary node performs a write transaction to the distributed storage, the primary node updates a transaction log to describe the transaction and to enable standby nodes to “synchronize a current state” of the database (i.e., “perform data synchronization”). As further detailed in ¶¶0043-45, when a transaction log is updated, standby nodes receive a notification which prompts the standby nodes to update metadata and data in a local cache.
Cocagne, Wang, and Jujjuri are considered analogous to the claimed invention because they all relate to the same field of allocating data access requests to nodes of a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne and Wang with the teachings of Jujjuri and realize a method of performing data synchronization on a secondary group of nodes after a node in a primary group performs a data writing request to a distributed database. Such a data synchronization method amounts to an improvement over other asynchronous approaches, thereby resulting in less potential for a node to commit a transaction without notifying other nodes, as disclosed in Jujjuri ¶0017: “Accordingly, when a node writes a record for a new transaction to the log, the node may notify the metadata server of the new transaction and its corresponding record in the distributed storage … Synchronizing transaction log information in this manner may be advantageous over the asynchronous approach noted above as transactions records are recorded as the transactions are being performed – thus, there is less potential for a node to commit a transactions without notifying the other nodes of the transaction.” [0017]
Regarding Claim 16,
The same motivation to combine provided in Claim 11 is equally applicable to Claim 16. The combined teachings of Cocagne and Wang discloses the following limitations:
The electronic device according to claim 11 (see Claim 11 limitation mappings above),
wherein … the data access request includes a data writing request (“a write operation” [0046]); and
the actions further include: determining (Fig. 10, block 580) whether the data access request is the data writing request (“the DS client module 34 determines the threshold number (e.g., a write threshold for a write operation, a read threshold for a read operation) and chooses the determined threshold number of encoded data slices for access” [0046]) – As taught in ¶0046, in order to select a number of encoded data slices to access for a write operation, a client module first determines a threshold corresponding to the type of data access request. One of ordinary skill in the art would accordingly understand that the data access request (received during block 576) is at least understood to be a write operation by block 580--;
in response to that the data access request is the data writing request, allocating the data writing request to a storage node (Fig. 10, block 584) – As previously discussed, during block 584, identified storage resources holding the selected encoded data slices are accessed.
Cocagne is silent regarding “primary” and “secondary” types of node groups. Specifically, Cocagne and Wang do not appear to explicitly disclose the following limitations:
the plurality of node groups include a primary node group and a secondary node group …
allocating the data writing request to a storage node in the primary node group, for the storage node in the primary node group to perform a data writing operation corresponding to the data writing request; and
after the storage node in the primary node group performs the data writing operation, sending a data synchronization instruction to a storage node in the secondary node group, to trigger the storage node in the secondary node group to perform data synchronization with the storage node in the primary node group.
However, Jujjuri discloses the following limitations:
the plurality of node groups (Fig. 1) include a primary node group (“Active”, Fig. 1) and a secondary (“Standby”, Fig. 1) node group (“Database system 10, in various embodiments, is implemented via nodes 130 and 140, which are configured to operate as a database cluster and process transaction requests … In various embodiments, database system 10 implements a high availability (HA) service using an active/standby topology in which one or more nodes are elected for writing data to distributed storage 110 on behalf of other nodes – shown as active node 130” [0019]) – As shown in Jujjuri Fig. 1, a plurality of nodes 130 and 140 perform data access requests directed to a distributed database 10, similar to how a plurality of DST EX units of Cocagne Fig. 9 perform data access requests directed to a distributed storage network. Examiner accordingly considers the groups of nodes depicted in Jujjuri Fig. 1 as analogous to the DST EX units of Cocagne Fig. 9. As shown in Jujjuri Fig. 1 and detailed in ¶0019, database nodes are grouped into “active” nodes (i.e., “a primary node group”) and “standby” nodes (i.e., “a secondary node group”)--…
allocating the data writing request to a storage node in the primary node group, for the storage node in the primary node group to perform a data writing operation corresponding to the data writing request (“Active node 130, in various embodiments, is configured to service requests to read and write data to distributed storage 10. Accordingly, active node 130 may receive, from a client device, a write transaction request 131 that causes node 130 to write a set of data to storage 110.” [0023] // Fig. 6, step 620 // “Method 600 begins in step 610 with an active node (e.g., node 130) receiving a request (e.g., request 131) to perform a transaction … in step 620, the active node commits the data to the distributed storage” [0044]) – As taught in Jujjuri, nodes within the “active” type of group perform write transactions to distributed storage--; and
after the storage node in the primary node group performs the data writing operation, sending a data synchronization instruction (“a notification” [0045]) to a storage node in the secondary node group (“a standby node” [0045]), to trigger the storage node in the secondary node group to perform data synchronization (“synchronize a current state of the database system” [0043]) with the storage node in the primary node group (“Method 600 is one embodiment of a method performed … to synchronize a current state of the database system among a plurality of nodes (e.g., nodes 130 and 140) … the active node commits the data to the distributed storage to update the state of the database system and causes the storing of metadata providing an indication (e.g., record 115) of the commitment in a transaction log … In some embodiment, a standby node receives a notification that the transaction log has been modified … In response to receiving the notification, in some embodiments, the standby node updates metadata (e.g., cache 420 and metadata 430) maintained at the standby node for servicing client requests (e.g., request 141)” [0043-45] // Fig. 6) – As shown in Fig. 6 and taught in ¶¶0043-45, after a primary node performs a write transaction to the distributed storage, the primary node updates a transaction log to describe the transaction and to enable standby nodes to “synchronize a current state” of the database (i.e., “perform data synchronization”). As further detailed in ¶¶0043-45, when a transaction log is updated, standby nodes receive a notification which prompts the standby nodes to update metadata and data in a local cache.
Cocagne, Wang, and Jujjuri are considered analogous to the claimed invention because they all relate to the same field of allocating data access requests to nodes of a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne and Wang with the teachings of Jujjuri and realize a method of performing data synchronization on a secondary group of nodes after a node in a primary group performs a data writing request to a distributed database. Such a data synchronization method amounts to an improvement over other asynchronous approaches, thereby resulting in less potential for a node to commit a transaction without notifying other nodes, as disclosed in Jujjuri ¶0017: “Accordingly, when a node writes a record for a new transaction to the log, the node may notify the metadata server of the new transaction and its corresponding record in the distributed storage … Synchronizing transaction log information in this manner may be advantageous over the asynchronous approach noted above as transactions records are recorded as the transactions are being performed – thus, there is less potential for a node to commit a transactions without notifying the other nodes of the transaction.” [0017]
Claims 7-9 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Cocagne further in view of Wang, Jujjuri and Algie.
Regarding Claim 7,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 7. The combined teachings of Cocagne, Wang, and Jujjuri disclose the following limitations:
The method according to claim 6 (see Claim 6 limitation mappings above),
wherein the data stored in the distributed database is divided into a plurality of data shards (Cocagne, “encoded data slices” [0038]), and at least one storage node included in each of the plurality of node groups stores at least one of the plurality of data shards (Cocagne, “a plurality of sets of encoded data slices, which are provided with their respective slice names to the storage units for storage” [0038] // Fig. 3) – As taught in Cocagne, “encoded data slices” (i.e., “a plurality of data shards”) are distributed across the DST EX Units--; and
the sending the data synchronization instruction to the storage node in the secondary node group includes (see Claim 6 limitation mappings above):
determining a secondary node group as a to-be-synchronized secondary node group (Jujjuri, “a standby node receives a notification that the transaction log has been modified” [0045] // ¶¶0043-45) – As previously discussed (see Claim 6 limitation mappings above), after an active node performs a write transaction, a transaction log is updated and a notification is sent to a standby node, prompting the standby node to synchronize to a current state of the database. In this context, examiner considers the standby node receiving the notification as “a to-be-synchronized secondary node group”--;
determining whether the to-be-synchronized secondary node group is a target secondary node group (Jujjuri, “database system 10 may monitor the health of each node 130 or 140 to determine if any issues of malfunctions occur” [0020]) – As taught in Jujjuri ¶0020, each node in the database system (e.g., including standby nodes 140) are monitored to determine whether or not an issue has taken place. In this context, examiner considers a standby node 140 which is identified as having an issue as “a target secondary node group”--
Jujjuri does not disclose that nodes identified as having an issue correspond to nodes on which a maintenance operation is being performed. In addition, the combined teachings of Cocagne and Jujjuri are silent regarding data migration as part of a maintenance task performed on a failed node. Specifically, the combined teachings of Cocagne, Wang, and Jujjuri do not explicitly disclose the following limitations:
a target secondary node group on which the online operation or maintenance task is being executed
However, Algie discloses the following limitations:
a target secondary node group (“DST execution units corresponding to the failing memory devices” [0298]) on which the online operation or maintenance task is being executed (“When the number of available encoded data slices compares unfavorably to a rebuilding threshold level, the DST process client module initiates a data salvaging process … the DST client module 34 issues, via the network 24, urgent read slice requests 480 for the encoded data slices to be recovered to the DST execution units corresponding to the failing memory devices” [0298]) – Examiner considers the DST execution units depicted in Algie Fig. 1 as analogous to the DST execution units of Cocagne Fig. 1. As taught in Algie ¶0298, a data salvaging process to recover data from failed memory devices is performed by transmitting urgent read slice requests to DST execution units associated with failing memories. In this context, one of ordinary skill in the art would understand that the DST execution units which are associated with failed memory devices would additionally be the DST execution units receiving an urgent read slice request (i.e., the “maintenance task is being executed” on identified failed memory devices).
Cocagne, Wang, Jujjuri, and Algie are considered analogous to the claimed invention because they all relate to the same field of scheduling both data access and maintenance tasks in a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne, Wang, and Jujjuri with the teachings of Algie and realize a method of performing a maintenance operation on a target node group by delivering a task to the target node group. Doing so improves the reliability of a distributed database by enabling quick recovery of encoded data slices from identified failing memories, as disclosed in Algie ¶0298: “For instance, the DST client module 34 issues, via the network 24, the urgent read slice requests 480 to DST execution units 1 and 2 to quickly recover recoverable encoded data slices from the memories 1-2, and 2-2.” [0298].
The combined teachings of Cocagne, Wang, Jujjuri, and Algie additionally disclose the following limitations:
determining a target data shard (Algie, “recoverable encoded data slices” [0298]) from a data shard stored in the target secondary node group in response to that the to-be-synchronized secondary node group is the target secondary node group, wherein the target data shard is a data shard on which data migration (Algie, “data salvaging” [0298]) is to be performed in a process of executing the online operation or maintenance task (Algie, “the DST client module 34 issues … the urgent read slice requests 480 to DST execution units 1 and 2 to quickly recover recoverable encoded data slices from the memories 1-2 and 2-2 … the DST client module 34 receives, via the network 24, urgent read slice responses … the DST client module 34 sends the extracted encoded data slices to another DST execution unit for temporary storage” [0298-299] // Jujjuri, “database system 10 may monitor the health of each node 130 or 140 to determine if any issues of malfunctions occur” [0020])) – Examiner considers DST units associated with failing memories of Algie as analogous to standby nodes 140 determined as having an issue of Jujjuri (i.e., “the target secondary node group” identified as having a maintenance operation in progress). As taught in Algie, the data salvaging process includes identifying “recoverable encoded data slices” (i.e., “a target data shard”) from identified failing memories and storing the recovered encoded data slices on different DST EX units. In this context, the recovered encoded data slices are effectively migrated out of a failing memory device into another memory device (i.e., “a data shard on which data migration is to be performed” as part of “executing” the “maintenance task”)--; and
sending a first data synchronization instruction (Algie, “urgent read slice requests” [0298]) to a storage node in the target secondary node group (Algie, “failing memory devices” [0298]), wherein the first data synchronization instruction is configured to instruct the storage node in the target secondary node group to perform data synchronization on a data shard other than the target data shard (Algie, “the DST client module 34 sends the extracted encoded data slices to another DST execution unit for temporary storage” [0299]) – As previously discussed, the data salvaging process effectively migrates recoverable encoded data slices to other memory devices using “urgent read slice requests” which instruct memories to recover data. In this context, examiner considers an urgent read slice request as “a first data synchronization instruction” which initiates data synchronization. As clarified in Algie ¶0299, data salvaging moves recovered encoded data slices into another memory associated with a different DST EX unit. In this context, data is effectively migrated from a first encoded slice (i.e., on the failing memory) to a different encoded slice in a different memory (i.e., from “the target data shard” to “a data shard other than the target data shard”)—
Regarding Claim 8,
The same motivation to combine provided in Claim 7 is equally applicable to Claim 8. The combined teachings of Cocagne, Wang, Jujjuri, and Algie disclose the following limitations:
The method according to claim 7, further comprising:
sending a second data synchronization instruction (Jujjuri, “a notification” [0045]) to the storage node in the target secondary node group after the online operation or maintenance task is completed for the target secondary node group, wherein the second data synchronization instruction is configured to instruct the storage node in the target secondary node group to perform data synchronization on the target data shard
(Cocagne, “periods of reduced or no activity … to perform critical maintenance functions” [0042] // Fig. 10; Jujjuri, “a standby node receives a notification that the transaction log has been modified … the standby node updates metadata … maintained at the standby node … In some embodiments … the standby node becoming a new active node” [0046] // “If data in a local cache is affected … a standby node 140 may update the cache to reflect the modification of data in storage 110 (e.g., by updating or invalidating a cache entry). This may allow … a newly elected node 140 to more quickly take on the role of an active node” [0024]) – As previously discussed (see Claims 1 and 6 limitation mappings above), nodes enter “periods of reduced or no activity” in order to perform critical maintenance (Cocagne ¶0042) but otherwise service data access requests (Cocagne Fig. 10). Standby nodes receive “a notification” when active nodes perform write operations, which prompts the standby node to bring data into its local cache thereby enabling the standby node can become a new active node (Jujjuri ¶0045). In this context, examiner considers the notification received by a standby node prompting a local cache update to enable transition to an active node as “a second data synchronization instruction” causing an update to data on the standby node (i.e., “data synchronization on the target data shard’). As previously discussed, nodes experience no activity during periods of critical maintenance (Cocagne ¶0042). One of ordinary skill in the art would accordingly understand that a standby node would update its local cache only after exiting the period of no activity (e.g., to perform maintenance).
Regarding Claim 9,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 9. The combined teachings of Cocagne, Wang, and Jujjuri disclose the following limitations:
The method according to claim 6 (see Claim 6 limitation mappings above), further comprising:
determining, in response to …, whether the node group is the primary node group (Jujjuri, “Implementing an HA service, database system 10 may monitor the health of each node 130 or 140 to determine if any issues or malfunctions occur. If issue is detected, database system 10 may hold an election to select a new active node 130” [0020]) – As taught in Jujjuri ¶0020, the health of each primary node 130 and standby node 140 is monitored by the database system to detect whether a given node has issues or has otherwise malfunctioned. When a primary node 130 is detected as having an issue, an election is held to select a new primary node. In this context, the database system 10 would understand that a node having an issue is a primary type of node (i.e., is “the primary node group”) in order for a new election to be initiated--
in response to that the node group is the primary node group, switching the primary node group to a new secondary node group and re-selecting a new primary node group from the secondary node groups except for the new secondary node group (Jujjuri, “Implementing an HA service, database system 10 may … hold an election to select a new active node 130 for writing data based on active node 130’s declining health … In such an example, database system 10 may detect that the current active node 130 has become nonresponsive and then promote another node to become active node 130 through an election.” [0020]) – As disclosed in Jujjuri ¶0020, an election “promotes another node” to become active node. In this context, the previous (i.e., declining) active node corresponds to “a new secondary node group” and the newly-promoted active node corresponds to “a new primary node group … except the new secondary node group”;
Although Jujjuri ¶0020 discloses that the election of a new primary node is prompted by the detection that a current primary node experiences issues, Jujjuri is silent regarding election of the new primary node being prompted by maintenance being performed on the current primary node. In addition, although Cocagne ¶¶0041-42 discloses that DST EX units are provided with periods of reduced or no activity in order to perform “critical maintenance functions”; Cocagne is silent regarding particular instructions received by DST EX units which cause critical maintenance to be performed. Specifically, the combined teachings of Cocagne, Wang, and Jujjuri do not explicitly disclose the following limitations:
a received instruction for executing an online operation or maintenance task on a node group of the plurality of node groups
However, Algie discloses the following limitations:
a received instruction (“urgent read requests” [0298]) for executing an online operation or maintenance task (“a data salvaging process” [0298]) on a node group of the plurality of node groups (“The DSN functions to select a data integrity maintenance process for maintaining integrity of stored data within the DST execution unit pool … the DST client module 34 receives error messages indicating that memories 1-2 and 2-2 are failing … the DST process client module 34 initiates a data salvaging processes to recover encoded data slices from the set of encoded data slices … For example, the DST client module 34 issues, via the network 24, urgent read slice requests 480 for the encoded data slices to be recovered to the DST execution units corresponding to the failing memory devices.” [0295-298]) – Examiner considers the DST execution units depicted in Algie Fig. 1 as analogous to the DST execution units of Cocagne Fig. 1. As taught in Algie, in order to perform “a data salvaging process” to recover encoded data slices (i.e., a “maintenance” operation), a DST client module receives “error messages” concerning particular failing memories (i.e., “a received instruction”) and subsequently delivers “urgent read slice requests” (i.e., “maintenance task[s]”) to the corresponding DST execution units having the failing memories.
Cocagne, Wang, Jujjuri, and Algie are considered analogous to the claimed invention because they all relate to the same field of scheduling both data access and maintenance tasks in a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne, Wang, and Jujjuri with the teachings of Algie and realize a method of performing a maintenance operation on a target node group by delivering a task to the target node group. Doing so improves the reliability of a distributed database by enabling quick recovery of encoded data slices from identified failing memories, as disclosed in Algie ¶0298: “For instance, the DST client module 34 issues, via the network 24, the urgent read slice requests 480 to DST execution units 1 and 2 to quickly recover recoverable encoded data slices from the memories 1-2, and 2-2.” [0298].
The combined teachings of Cocagne, Wang, Jujjuri, and Algie additionally disclose the following limitations:
after the primary node group is successfully switched to the new secondary node group, delivering the online operation or maintenance task to the new secondary node group (Jujjuri, “If an issue is detected, database system 10 may hold an election to select a new active node 130 for writing data based on active node 130’s declining health” [0020]; ¶0040 // Algie, “For example, the DST client module 34 issues, via the network 24, urgent read slice requests 480 for the encoded data slices to be recovered to the DST execution units corresponding to the failing memory devices” [0298] // Cocagne, “periods of reduced or no activity can be used to enable particular memory devices to perform critical maintenance functions” [0042]) – As taught in Jujjuri, election of a new active node is prompted by the declining health of the active primary node. As taught in Algie, tasks (e.g., “urgent read requests”) are sent to failing memory devices (i.e., failing nodes) to prompt data salvaging for failing memory devices. As clarified in Cocagne, data access requests are not sent to DST EX Units which are undergoing necessary maintenance (e.g., such as the data salvaging process of Algie). One of ordinary skill in the art would accordingly understand that a previous active node (i.e., “the new secondary node”) would be instructed to undergo a maintenance operation (i.e., thus entering a period without data access requests) after an election for a new active node (i.e., the “new primary node group”) has been completed to ensure that there is at least one active node during any given time (see Jujjuri ¶0040).
Regarding Claim 17,
The same motivation to combine provided in Claim 16 is equally applicable to Claim 17. The combined teachings of Cocagne, Wang, and Jujjuri disclose the following limitations:
The electronic device according to claim 16 (see Claim 16 limitation mappings above),
wherein the data stored in the distributed database is divided into a plurality of data shards (Cocagne, “encoded data slices” [0038]), and at least one storage node included in each of the plurality of node groups stores at least one of the plurality of data shards (Cocagne, “a plurality of sets of encoded data slices, which are provided with their respective slice names to the storage units for storage” [0038] // Fig. 3) – As taught in Cocagne, “encoded data slices” (i.e., “a plurality of data shards”) are distributed across the DST EX Units--; and
the sending the data synchronization instruction to the storage node in the secondary node group includes (see Claim 16 limitation mappings above):
determining a secondary node group as a to-be-synchronized secondary node group (Jujjuri, “a standby node receives a notification that the transaction log has been modified” [0045] // ¶¶0043-45) – As previously discussed (see Claim 16 limitation mappings above), after an active node performs a write transaction, a transaction log is updated and a notification is sent to a standby node, prompting the standby node to synchronize to a current state of the database. In this context, examiner considers the standby node receiving the notification as “a to-be-synchronized secondary node group”--;
determining whether the to-be-synchronized secondary node group is a target secondary node group (Jujjuri, “database system 10 may monitor the health of each node 130 or 140 to determine if any issues of malfunctions occur” [0020]) – As taught in Jujjuri ¶0020, each node in the database system (e.g., including standby nodes 140) are monitored to determine whether or not an issue has taken place. In this context, examiner considers a standby node 140 which is identified as having an issue as “a target secondary node group”--
Jujjuri does not disclose that nodes identified as having an issue correspond to nodes on which a maintenance operation is being performed. In addition, the combined teachings of Cocagne and Jujjuri are silent regarding data migration as part of a maintenance task performed on a failed node. Specifically, the combined teachings of Cocagne, Wang, and Jujjuri do not explicitly disclose the following limitations:
a target secondary node group on which the online operation or maintenance task is being executed
However, Algie discloses the following limitations:
a target secondary node group (“DST execution units corresponding to the failing memory devices” [0298]) on which the online operation or maintenance task is being executed (“When the number of available encoded data slices compares unfavorably to a rebuilding threshold level, the DST process client module initiates a data salvaging process … the DST client module 34 issues, via the network 24, urgent read slice requests 480 for the encoded data slices to be recovered to the DST execution units corresponding to the failing memory devices” [0298]) – Examiner considers the DST execution units depicted in Algie Fig. 1 as analogous to the DST execution units of Cocagne Fig. 1. As taught in Algie ¶0298, a data salvaging process to recover data from failed memory devices is performed by transmitting urgent read slice requests to DST execution units associated with failing memories. In this context, one of ordinary skill in the art would understand that the DST execution units which are associated with failed memory devices would additionally be the DST execution units receiving an urgent read slice request (i.e., the “maintenance task is being executed” on identified failed memory devices).
Cocagne, Wang, Jujjuri, and Algie are considered analogous to the claimed invention because they all relate to the same field of scheduling both data access and maintenance tasks in a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne, Wang, and Jujjuri with the teachings of Algie and realize a method of performing a maintenance operation on a target node group by delivering a task to the target node group. Doing so improves the reliability of a distributed database by enabling quick recovery of encoded data slices from identified failing memories, as disclosed in Algie ¶0298: “For instance, the DST client module 34 issues, via the network 24, the urgent read slice requests 480 to DST execution units 1 and 2 to quickly recover recoverable encoded data slices from the memories 1-2, and 2-2.” [0298].
The combined teachings of Cocagne, Wang, Jujjuri, and Algie additionally disclose the following limitations:
determining a target data shard (Algie, “recoverable encoded data slices” [0298]) from a data shard stored in the target secondary node group in response to that the to-be-synchronized secondary node group is the target secondary node group, wherein the target data shard is a data shard on which data migration (Algie, “data salvaging” [0298]) is to be performed in a process of executing the online operation or maintenance task (Algie, “the DST client module 34 issues … the urgent read slice requests 480 to DST execution units 1 and 2 to quickly recover recoverable encoded data slices from the memories 1-2 and 2-2 … the DST client module 34 receives, via the network 24, urgent read slice responses … the DST client module 34 sends the extracted encoded data slices to another DST execution unit for temporary storage” [0298-299] // Jujjuri, “database system 10 may monitor the health of each node 130 or 140 to determine if any issues of malfunctions occur” [0020])) – Examiner considers DST units associated with failing memories of Algie as analogous to standby nodes 140 determined as having an issue of Jujjuri (i.e., “the target secondary node group” identified as having a maintenance operation in progress). As taught in Algie, the data salvaging process includes identifying “recoverable encoded data slices” (i.e., “a target data shard”) from identified failing memories and storing the recovered encoded data slices on different DST EX units. In this context, the recovered encoded data slices are effectively migrated out of a failing memory device into another memory device (i.e., “a data shard on which data migration is to be performed” as part of “executing” the “maintenance task”)--; and
sending a first data synchronization instruction (Algie, “urgent read slice requests” [0298]) to a storage node in the target secondary node group (Algie, “failing memory devices” [0298]), wherein the first data synchronization instruction is configured to instruct the storage node in the target secondary node group to perform data synchronization on a data shard other than the target data shard (Algie, “the DST client module 34 sends the extracted encoded data slices to another DST execution unit for temporary storage” [0299]) – As previously discussed, the data salvaging process effectively migrates recoverable encoded data slices to other memory devices using “urgent read slice requests” which instruct memories to recover data. In this context, examiner considers an urgent read slice request as “a first data synchronization instruction” which initiates data synchronization. As clarified in Algie ¶0299, data salvaging moves recovered encoded data slices into another memory associated with a different DST EX unit. In this context, data is effectively migrated from a first encoded slice (i.e., on the failing memory) to a different encoded slice in a different memory (i.e., from “the target data shard” to “a data shard other than the target data shard”)—
Regarding Claim 18,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 18. The combined teachings of Cocagne, Wang, Jujjuri, and Algie disclose the following limitations:
The electronic device according to claim 17, further comprising:
sending a second data synchronization instruction (Jujjuri, “a notification” [0045]) to the storage node in the target secondary node group after the online operation or maintenance task is completed for the target secondary node group, wherein the second data synchronization instruction is configured to instruct the storage node in the target secondary node group to perform data synchronization on the target data shard
(Cocagne, “periods of reduced or no activity … to perform critical maintenance functions” [0042] // Fig. 10; Jujjuri, “a standby node receives a notification that the transaction log has been modified … the standby node updates metadata … maintained at the standby node … In some embodiments … the standby node becoming a new active node” [0046] // “If data in a local cache is affected … a standby node 140 may update the cache to reflect the modification of data in storage 110 (e.g., by updating or invalidating a cache entry). This may allow … a newly elected node 140 to more quickly take on the role of an active node” [0024]) – As previously discussed (see Claims 11 and 16 limitation mappings above), nodes enter “periods of reduced or no activity” in order to perform critical maintenance (Cocagne ¶0042) but otherwise service data access requests (Cocagne Fig. 10). Standby nodes receive “a notification” when active nodes perform write operations, which prompts the standby node to bring data into its local cache thereby enabling the standby node can become a new active node (Jujjuri ¶0045). In this context, examiner considers the notification received by a standby node prompting a local cache update to enable transition to an active node as “a second data synchronization instruction” causing an update to data on the standby node (i.e., “data synchronization on the target data shard’). As previously discussed, nodes experience no activity during periods of critical maintenance (Cocagne ¶0042). One of ordinary skill in the art would accordingly understand that a standby node would update its local cache only after exiting the period of no activity (e.g., to perform maintenance).
Regarding Claim 19,
The same motivation to combine provided in Claim 16 is equally applicable to Claim 19. The combined teachings of Cocagne, Wang, and Jujjuri disclose the following limitations:
The electronic device according to claim 16 (see Claim 16 limitation mappings above), wherein the actions further include:
determining, in response to …, whether the node group is the primary node group (Jujjuri, “Implementing an HA service, database system 10 may monitor the health of each node 130 or 140 to determine if any issues or malfunctions occur. If issue is detected, database system 10 may hold an election to select a new active node 130” [0020]) – As taught in Jujjuri ¶0020, the health of each primary node 130 and standby node 140 is monitored by the database system to detect whether a given node has issues or has otherwise malfunctioned. When a primary node 130 is detected as having an issue, an election is held to select a new primary node. In this context, the database system 10 would understand that a node having an issue is a primary type of node (i.e., is “the primary node group”) in order for a new election to be initiated--
in response to that the node group is the primary node group, switching the primary node group to a new secondary node group and re-selecting a new primary node group from the secondary node groups except for the new secondary node group (Jujjuri, “Implementing an HA service, database system 10 may … hold an election to select a new active node 130 for writing data based on active node 130’s declining health … In such an example, database system 10 may detect that the current active node 130 has become nonresponsive and then promote another node to become active node 130 through an election.” [0020]) – As disclosed in Jujjuri ¶0020, an election “promotes another node” to become active node. In this context, the previous (i.e., declining) active node corresponds to “a new secondary node group” and the newly-promoted active node corresponds to “a new primary node group … except the new secondary node group”;
Although Jujjuri ¶0020 discloses that the election of a new primary node is prompted by the detection that a current primary node experiences issues, Jujjuri is silent regarding election of the new primary node being prompted by maintenance being performed on the current primary node. In addition, although Cocagne ¶¶0041-42 discloses that DST EX units are provided with periods of reduced or no activity in order to perform “critical maintenance functions”; Cocagne is silent regarding particular instructions received by DST EX units which cause critical maintenance to be performed. Specifically, the combined teachings of Cocagne, Wang, and Jujjuri do not explicitly disclose the following limitations:
a received instruction for executing an online operation or maintenance task on a node group of the plurality of node groups
However, Algie discloses the following limitations:
a received instruction (“urgent read requests” [0298]) for executing an online operation or maintenance task (“a data salvaging process” [0298]) on a node group of the plurality of node groups (“The DSN functions to select a data integrity maintenance process for maintaining integrity of stored data within the DST execution unit pool … the DST client module 34 receives error messages indicating that memories 1-2 and 2-2 are failing … the DST process client module 34 initiates a data salvaging processes to recover encoded data slices from the set of encoded data slices … For example, the DST client module 34 issues, via the network 24, urgent read slice requests 480 for the encoded data slices to be recovered to the DST execution units corresponding to the failing memory devices.” [0295-298]) – Examiner considers the DST execution units depicted in Algie Fig. 1 as analogous to the DST execution units of Cocagne Fig. 1. As taught in Algie, in order to perform “a data salvaging process” to recover encoded data slices (i.e., a “maintenance” operation), a DST client module receives “error messages” concerning particular failing memories (i.e., “a received instruction”) and subsequently delivers “urgent read slice requests” (i.e., “maintenance task[s]”) to the corresponding DST execution units having the failing memories.
Cocagne, Wang, Jujjuri, and Algie are considered analogous to the claimed invention because they all relate to the same field of scheduling both data access and maintenance tasks in a distributed database environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne, Wang, and Jujjuri with the teachings of Algie and realize a method of performing a maintenance operation on a target node group by delivering a task to the target node group. Doing so improves the reliability of a distributed database by enabling quick recovery of encoded data slices from identified failing memories, as disclosed in Algie ¶0298: “For instance, the DST client module 34 issues, via the network 24, the urgent read slice requests 480 to DST execution units 1 and 2 to quickly recover recoverable encoded data slices from the memories 1-2, and 2-2.” [0298].
The combined teachings of Cocagne, Wang, Jujjuri, and Algie additionally disclose the following limitations:
after the primary node group is successfully switched to the new secondary node group, delivering the online operation or maintenance task to the new secondary node group (Jujjuri, “If an issue is detected, database system 10 may hold an election to select a new active node 130 for writing data based on active node 130’s declining health” [0020]; ¶0040 // Algie, “For example, the DST client module 34 issues, via the network 24, urgent read slice requests 480 for the encoded data slices to be recovered to the DST execution units corresponding to the failing memory devices” [0298] // Cocagne, “periods of reduced or no activity can be used to enable particular memory devices to perform critical maintenance functions” [0042]) – As taught in Jujjuri, election of a new active node is prompted by the declining health of the active primary node. As taught in Algie, tasks (e.g., “urgent read requests”) are sent to failing memory devices (i.e., failing nodes) to prompt data salvaging for failing memory devices. As clarified in Cocagne, data access requests are not sent to DST EX Units which are undergoing necessary maintenance (e.g., such as the data salvaging process of Algie). One of ordinary skill in the art would accordingly understand that a previous active node (i.e., “the new secondary node”) would be instructed to undergo a maintenance operation (i.e., thus entering a period without data access requests) after an election for a new active node (i.e., the “new primary node group”) has been completed to ensure that there is at least one active node during any given time (see Jujjuri ¶0040).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Cocagne further in view of Wang and Subramanian et al. (US 20250265013 A1)(cited by examiner in previous action)(hereafter referred to as Subramanian).
Regarding Claim 10,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 10. The combined teachings of Cocagne and Wang discloses the following limitations:
The method according to claim 1 (see Claim 1 limitation mappings above),
Cocagne and Wang are silent regarding the following limitations:
wherein the distributed database is a distributed graph database, and the data stored in the distributed database is graph data.
However, Subramanian discloses the following limitations:
wherein the distributed database is a distributed graph database (“a connected graph data exchange database” [0023]), and the data stored in the distributed database is graph data (“A data exchange asset may include an attribute … the attribute may indicate how an asset is indexed and/or archived in a connected graph data exchange database and/or data exchange system … The data exchange system may arrange and/or organize the data exchange assets into a graph-based hierarchy.” [0023]) – As taught in Subramanian, a “connected graph data exchange database” organizes data into “a graph-based hierarchy” (i.e., stores “graph data”).
Cocagne, Wang, and Subramanian are considered analogous to the claimed invention because they all relate to the same field of distributed database management. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cocagne and Wang with the teachings of Subramanian and realize a distributed graph database storing graph data. Using a data exchange type of graph database facilitates the process of sending, storing, and searching data, thereby allowing data to be shared between different computer programs, as disclosed in Subramanian ¶0001-02: “As the world increasingly moves towards the use of electronic storage as the predominant storage method, the amount and type of data in storage continues to expand. To manage this data, some systems rely on a data exchange. A data exchange may facilitate the process of sending, storing, and searching data. Data exchanges hold vast amounts of data in many different formats and platforms as well as perform other functions … By doing so, the data exchange may allow data to be shared between different computer programs.” [0001-02]
Response to Arguments
The previous 35 U.S.C. 112(b) rejection of Claim 19 is withdrawn in view of instant claim amendments.
The previous objections of Claims 5 and 15 are withdrawn in view of instant claim amendments.
The previous objection to the Abstract is withdrawn in view of the replacement abstract.
Applicant’s arguments with respect to claim(s) 1-20have been considered but are moot in view of the newly-identified Wang reference 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.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm EST.
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, Rocío del Mar Pérez-Vélez can be reached at 571-270-5935. 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.
/J.S.M./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights