DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 2-5, 7, 8, 10, 11, 13-21 are pending in this application.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on October 22nd, 2025 has been entered.
Response to Amendment
This office action is in response to applicant’s communication filed on October 22nd, 2025. The applicant’s remark and amendments to the claims were consider with the results that follow.
In response to the last office action, claims 2, 7, 10, 11, 13, 16, 17, and 20 have been amended. Claims 1, 6, 9, and 12 have been canceled. As a result, claims 2-5, 7, 8, 10, 11, 13-21 are pending in this application.
Response to Arguments
The applicant's argument, detailed on page 9 of the remarks filed on October 22, 2025, asserts that the examiner agreed that the amendments to incorporate paragraph [0067] of the specification would place the independent claims in condition for allowance.
Examiner respectfully disagrees. With regard to the allowability, applicant’s arguments with respect to claims 2, 13, and 20 submitted on pg. 9 of the remarks, filed on October 22nd, 2025 have been considered. However, there was no prior agreement for allowability of any claims. Examiner previously indicated that amendments will have to be further searched against prior art to determine allowability.
Applicant’s remaining arguments with respect to the rejections raised have been considered but are moot in view of the new grounds of rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 10-11, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S Patent Application Publication 2013/0218840 issued to SMITH et al. (hereinafter as "SMITH") in view of U.S Patent Application Publication 2014/0156618 issued to Castellano et al. (hereinafter as “Castellano”) in further view of U.S Patent 9,805,108 issued to Merriman et al. (hereinafter as “Merriman”).
Regarding claim 2, SMITH teaches a system, comprising: a processor associated with a first node of a plurality of nodes (SMITH: [0023]; One or more compute nodes collect a plurality of node specific snapshots generated by a plurality of distributed nodes that implements the eventually-consistent data store. [0050]; For example, each of the nodes of cluster 600 also includes a processor, a memory, a NIC, and one or more non-volatile storage devices), wherein
the processor is configured to: receive from a client a first message to perform a write operation associated with a key-value pair (SMITH: [0033]; Each row 311 in a column family 310 may define a number of different columns that represent various values associated with a particular key 312. [0037]; The node to which client computer 181 connects acts as a coordinator for requests transmitted by client computer 181 to read from or write to the data store. Each request is associated with a particular key 312 and a particular column family 310), wherein the message at least includes a key, a version number associated with the key-value pair (SMITH: [0032]; As key-value pairs are added to the data store, a row 311 will be added to the column family 310. Each row includes exactly one key 312 and one or more columns (e.g., 313, 314, 315, etc.). Key 312 is a universally unique identifier (UUID) that associates that key 312 to the values stored for each column. [0037]; The node to which client computer 181 connects acts as a coordinator for requests transmitted by client computer 181 to read from or write to the data store. Each request is associated with a particular key 312 and a particular column family 310. Each row 311 in a column family 310 may define a number of different columns that represent various values associated with a particular key 312), and a sequence number associated with the write operation (SMITH: [0032]-[0033]; The node to which client computer 181 connects acts as a coordinator for requests transmitted by client computer 181 to read from or write to the data store. As key-value pairs are added to the data store, a row 311 will be added to the column family 310. Columns (e.g., 313, 314, 315, etc.) within each column family 310 are associated with an identifier (e.g., a string) and a timestamp (e.g., 313-1, 314-1, 315-1, etc.). Each row 311 in a column family 310 may define a number of different columns that represent various values associated with a particular key 312. [0037]; Each request is associated with a particular key 312 and a particular column family 310);
select, according to a hashing algorithm, at least one secondary node of the plurality of nodes to which to replicate the key-value pair and generate a second message to replicate the key-value pair to the at least one secondary node of the plurality of nodes (SMITH: [0037]; For example, keys 312 may be hashed to generate an MD5 hash value, that randomly assigns a particular key 312 to one of the nodes 131 of the cluster 400. Cluster 400 may also be associated with a replication factor that ensures that data is stored redundantly such that a failure in one node does not stop requests to access the data store from being serviced by the cluster 400. For example, a replication factor of 3 reflects that data is stored on three nodes. [0042]; Application 520 is configured to store key-value pairs in the data store and perform backend operations to ensure that the data store is eventually-consistent across every node. As a request is received by a node, the request is added to a commit log 530, stored in storage device 128. The commit log 530 acts like a buffer that allows requests to be processed asynchronously from when the requests arrive at the node);
select, according to the hashing algorithm, at least one tertiary node of the plurality of nodes and generate a third message to replicate the key-value pair to the at least one tertiary node of the plurality of nodes (SMITH: [0037]; For example, keys 312 may be hashed to generate an MD5 hash value, that randomly assigns a particular key 312 to one of the nodes 131 of the cluster 400. Cluster 400 may also be associated with a replication factor that ensures that data is stored redundantly such that a failure in one node does not stop requests to access the data store from being serviced by the cluster 400. For example, a replication factor of 3 reflects that data is stored on three nodes. [0042]; Application 520 is configured to store key-value pairs in the data store and perform backend operations to ensure that the data store is eventually-consistent across every node. As a request is received by a node, the request is added to a commit log 530, stored in storage device 128. The commit log 530 acts like a buffer that allows requests to be processed asynchronously from when the requests arrive at the node); and
a memory coupled to the processor, wherein the memory provides the processor with instructions (SMITH: [0050]; For example, each of the nodes of cluster 600 also includes a processor, a memory, a NIC, and one or more non-volatile storage devices).
SMITH does not explicitly teach in response to receiving the first message: compare the version number associated with the key-value pair included in the first message with a stored version number associated with the key- value pair, wherein the stored version number associated with the key-value pair is incremented each time a value is written to the key-value pair; determine whether the version number associated with the key- value pair included in the first message is equal to the stored version number associated with the key-value pair; and perform, in response to a determination that the version number associated with the key-value pair included in the first message is equal to the stored version number associated with the key-value pair, the write operation and increment the stored version number associated with the key-value pair;
However, Castellano teaches in response to receiving the first message: compare the version number associated with the key-value pair included in the first message with a stored version number associated with the key- value pair, wherein the stored version number associated with the key-value pair is incremented each time a value is written to the key-value pair (Castellano: [0014]; Upon receiving a user invocation of a particular operation, DTKV service 104-1 to 104-N can execute the operation and return a response (if appropriate) to the user. [0036]; Data log files 106-1 to 106-M store the actual key-value pairs maintained by DTKV store 100. Each data log file 106-1 to 106-M can be shared across DTKV services 104-1 to 104-N such that it is readable and writable by each DTKV service. [0045]; In further embodiments, DTKV services 104-1 to 104-N are configured such they access/modify data log files 106-1 to 106-M in the context of file versions. [0058]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version);
determine whether the version number associated with the key- value pair included in the first message is equal to the stored version number associated with the key-value pair (Castellano: [0010]; The DTKV store can include a set of nodes and can execute, on each node, key-value operations (e.g., PUT, GET, DELETE, etc.) that enable users to store and retrieve data in the form of key-value pairs. [0014]; Upon receiving a user invocation of a particular operation, DTKV service 104-1 to 104-N can execute the operation and return a response (if appropriate) to the user. [0045]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version); and
perform, in response to a determination that the version number associated with the key-value pair included in the first message is equal to the stored version number associated with the key-value pair (Castellano: [0058]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version),
the write operation and increment the stored version number associated with the key-value pair (Castellano: [0036]; Data log files 106-1 to 106-M store the actual key-value pairs maintained by DTKV store 100. Each data log file 106-1 to 106-M can be shared across DTKV services 104-1 to 104-N such that it is readable and writable by each DTKV service. [0058]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version);
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify SMITH (teaches receives from a client a message to perform a write operation associated with a key-value pair, wherein the message at least includes a key, a version number associated with the key-value pair) with the teachings of Castellano (teaches compares the version number associated with the key-value pair included in the message with a stored version number associated with the key-value pair, wherein the stored version number associated with the key-value pair is incremented each time a value is written to the key-value pair; determines whether the version number associated with the key-value pair included in the message is equal to the stored version number associated with the key-value pair; and performs the write operation and increments the stored version number associated with the key-value pair in response to a determination that the version number associated with the key-value pair included in the message is equal to the stored version number associated with the key-value pair). One of ordinary skill in the art would have been motivated to make such a combination of improving the scalability by utilizing lock modes and achieving a system that provide the particular target to achieve the system to obtaining the resource based on the scalability limit (See: Castellano [0067]). In addition, the references (SMITH and Castellano) teach features that are directed to analogous art and they are directed to the same field of endeavor as SMITH and Castellano are directed to utilizes key value management and providing data according to distributing.
Although, SMITH teaches select, according to a hashing algorithm, at least one secondary node of the plurality of nodes to which to replicate the key-value pair and generate a second message and third message to replicate the key-value pair to the at least one secondary node of the plurality of nodes and at least one tertiary node of the plurality of nodes (See SMITH: [0037]; For example, keys 312 may be hashed to generate an MD5 hash value, that randomly assigns a particular key 312 to one of the nodes 131 of the cluster 400. Cluster 400 may also be associated with a replication factor that ensures that data is stored redundantly such that a failure in one node does not stop requests to access the data store from being serviced by the cluster 400. For example, a replication factor of 3 reflects that data is stored on three nodes). The modification of SMITH and Castellano teaches claimed invention substantially as claimed, however the modification of SMITH and Castellano does not explicitly teach in response to incrementing the stored version number, replicate the key-value pair to at least one secondary node of the plurality of nodes; and in response to detecting a failure of the at least one secondary node, replicate the key-value pair to at least one tertiary node of the plurality of nodes; maintain multiple copies of location metadata indicating which of the plurality of nodes store the key-value pair; batch at least one of the second message or the third message with additional messages for sending to at least one of the secondary node of the plurality of nodes or the tertiary node of the plurality of nodes.
However, Merriman teaches in response to incrementing the stored version number, replicate the key-value pair to at least one secondary node of the plurality of nodes (Merriman: Col 35, lines 11-15; Each operation in the log can be associated with a time and an increasing value so that an order can be determined for each operation. In one example, a monotonically increasing to value is employed and associated with each operation. Each operation can also be time stamped. Col 63, lines 40-43; new data elements that are added receive a key value that is greater than any previously used key value. A simple example of such a key pattern includes a monotonically increasing key value. Col 35, lines 63-63; Replication from a primary to secondary nodes can include a commitment operation): and
in response to detecting a failure of the at least one secondary node, replicate the key-value pair to at least one tertiary node of the plurality of nodes (Merriman: Col 34, lines 47-52; For example, a node may be added or initialized into a set using a synchronization operation that causes the node to capture a complete copy of a database as it exists on another node. Once synchronization is complete, replication operations can proceed for that node. Col 36, lines 29-31; Secondary nodes, as well as the primary, can monitor communication status with other nodes to determine if a failure has occurred. Col 38, lines 22-24; Although automatic fail-over processing can result in lost data, an operation becomes durable once replicated across a majority of the nodes within the replica set. Col 58, lines 57-60; A replica set can be configured to perform asynchronous replication across a series of nodes);
maintain multiple copies of location metadata indicating which of the plurality of nodes store the key-value pair (Merriman: Col 48, lines 8-13; Metadata for the shard cluster can include, for example, information on the ranges of data stored in each partition, information associated with managing the shard cluster, partition counts, number of shard servers, data index information, partition size constraints, data distribution thresholds, among other options. Col 52, lines 27-31; The shard key ranges associated with a given partition can be used by the shard cluster (e.g. through a router process) to direct database requests to appropriate shard servers hosting the particular partition. Col 58, lines 62-64; By implementing each shard as a replica set, the shard cluster can provide for high availability and high consistency in the underlying data);
batch at least one of the second message or the third message with additional messages for sending to at least one of the secondary node of the plurality of nodes or the tertiary node of the plurality of nodes (Merriman: Col 30, lines 59-60; replicates changes to the database throughout the set of nodes asynchronously. Col 34, lines 59-64; The operations are then transmitted asynchronously from the primary node to its respective secondary nodes. In some settings , the secondary nodes are configured to periodically query the operation log of the primary node to determine any operations that should be retrieved and executed) {Examiner correlates the batching a second or third message with the additional message to the secondary or tertiary node of the plurality of nodes according to transmitting asynchronously to its respective secondary by periodically query any operations (receiving sets of message) that should be retrieved and to be executed to that secondary nodes));
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify SMITH (teaches receives from a client a message to perform a write operation associated with a key-value pair, wherein the message at least includes a key, a version number associated with the key-value pair) with the teachings of Castellano (teaches compares the version number associated with the key-value pair included in the message with a stored version number associated with the key-value pair, wherein the stored version number associated with the key-value pair is incremented each time a value is written to the key-value pair; determines whether the version number associated with the key-value pair included in the message is equal to the stored version number associated with the key-value pair; and performs the write operation and increments the stored version number associated with the key-value pair in response to a determination that the version number associated with the key-value pair included in the message is equal to the stored version number associated with the key-value pair) to further include Merriman (teaches in response to incrementing the stored version number, replicate the key-value pair to at least one secondary node of the plurality of nodes; and in response to detecting a failure of the at least one secondary node, replicate the key-value pair to at least one tertiary node of the plurality of nodes). One of ordinary skill in the art would have been motivated to make such a combination of improving mirroring data for high availability and disaster recovery to prevent data from being lost (See: Merriman: Col 22, lines 26-29)). In addition, the references (SMITH, Castellano, and Merriman) teach features that are directed to analogous art and they are directed to the same field of endeavor as SMITH, Castellano, and Merriman are directed to utilizes key value management and providing data according to distributing.
Regarding claim 10, the modification of SMITH, Castellano, and Merriman teaches claimed invention substantially as claimed, and SMITH further teaches
the plurality of nodes is configured to store corresponding portions of a distributed key-value store (SMITH: [0031]-[0032]; Key-value data stores are better in this manner because they support operations that perform better when distributed among many individual nodes. Node 300 implements a persistent distributed multi-dimensional map (i.e., an associative array). In other words, node 300 implements a structured key-value data store in which each key may map to one or more values. [0039]; The data store is implemented using various data structures stored on a plurality of nodes in cluster 400. [0045]; each node 131 may contain a plurality of column families 310. Thus, memory capacity for each node may be insufficient to store all of the data).
Regarding claim 11, the modification of SMITH, Castellano, and Merriman teaches claimed invention substantially as claimed, and SMITH further teaches
a value associated with the key is stored in at least two of the plurality of nodes (SMITH: [0031]-[0032]; Key-value data stores are better in this manner because they support operations that perform better when distributed among many individual nodes. Node 300 implements a persistent distributed multi-dimensional map (i.e., an associative array). In other words, node 300 implements a structured key-value data store in which each key may map to one or more values).
Regarding claim 13, SMITH teaches a method, comprising: receiving from a client a first message to perform a write operation associated with a key- value pair (SMITH: [0033]; Each row 311 in a column family 310 may define a number of different columns that represent various values associated with a particular key 312. [0037]; The node to which client computer 181 connects acts as a coordinator for requests transmitted by client computer 181 to read from or write to the data store. Each request is associated with a particular key 312 and a particular column family 310), wherein
the first message at least includes a key, a version number associated with the key-value pair (SMITH: [0032]; [0032]-[0033]; As key-value pairs are added to the data store, a row 311 will be added to the column family 310. Columns (e.g., 313, 314, 315, etc.) within each column family 310 are associated with an identifier (e.g., a string) and a timestamp (e.g., 313-1, 314-1, 315-1, etc.). Each row 311 in a column family 310 may define a number of different columns that represent various values associated with a particular key 312. [0037]; The node to which client computer 181 connects acts as a coordinator for requests transmitted by client computer 181 to read from or write to the data store. Each request is associated with a particular key 312 and a particular column family 310. Each row 311 in a column family 310 may define a number of different columns that represent various values associated with a particular key 312), and
a sequence number associated with the write operation (SMITH: [0032]-[0033]; As key-value pairs are added to the data store, a row 311 will be added to the column family 310. Columns (e.g., 313, 314, 315, etc.) within each column family 310 are associated with an identifier (e.g., a string) and a timestamp (e.g., 313-1, 314-1, 315-1, etc.). Each row 311 in a column family 310 may define a number of different columns that represent various values associated with a particular key 312. [0037]; Each request is associated with a particular key 312 and a particular column family 310);
select, according to a hashing algorithm, at least one secondary node of the plurality of nodes to which to replicate the key-value pair and generate a second message to replicate the key-value pair to the at least one secondary node of the plurality of nodes (SMITH: [0037]; For example, keys 312 may be hashed to generate an MD5 hash value, that randomly assigns a particular key 312 to one of the nodes 131 of the cluster 400. Cluster 400 may also be associated with a replication factor that ensures that data is stored redundantly such that a failure in one node does not stop requests to access the data store from being serviced by the cluster 400. For example, a replication factor of 3 reflects that data is stored on three nodes. [0042]; Application 520 is configured to store key-value pairs in the data store and perform backend operations to ensure that the data store is eventually-consistent across every node. As a request is received by a node, the request is added to a commit log 530, stored in storage device 128. The commit log 530 acts like a buffer that allows requests to be processed asynchronously from when the requests arrive at the node);
select, according to the hashing algorithm, at least one tertiary node of the plurality of nodes and generate a third message to replicate the key-value pair to the at least one tertiary node of the plurality of nodes (SMITH: [0037]; For example, keys 312 may be hashed to generate an MD5 hash value, that randomly assigns a particular key 312 to one of the nodes 131 of the cluster 400. Cluster 400 may also be associated with a replication factor that ensures that data is stored redundantly such that a failure in one node does not stop requests to access the data store from being serviced by the cluster 400. For example, a replication factor of 3 reflects that data is stored on three nodes. [0042]; Application 520 is configured to store key-value pairs in the data store and perform backend operations to ensure that the data store is eventually-consistent across every node. As a request is received by a node, the request is added to a commit log 530, stored in storage device 128. The commit log 530 acts like a buffer that allows requests to be processed asynchronously from when the requests arrive at the node);
SMITH does not explicitly teach in response to receiving the first message: compare the version number associated with the key-value pair included in the first message with a stored version number associated with the key- value pair, wherein the stored version number associated with the key-value pair is incremented each time a value is written to the key-value pair; determine whether the version number associated with the key- value pair included in the first message is equal to the stored version number associated with the key-value pair; and perform, in response to a determination that the version number associated with the key-value pair included in the first message is equal to the stored version number associated with the key-value pair, the write operation and increment the stored version number associated with the key-value pair;
However, Castellano teaches in response to receiving the first message: comparing the version number associated with the key-value pair included in the first message with a stored version number associated with the key-value pair, wherein the stored version number associated with the key-value pair is incremented each time a value is written to the key-value pair (Castellano: [0014]; Upon receiving a user invocation of a particular operation, DTKV service 104-1 to 104-N can execute the operation and return a response (if appropriate) to the user. [0036]; Data log files 106-1 to 106-M store the actual key-value pairs maintained by DTKV store 100. Each data log file 106-1 to 106-M can be shared across DTKV services 104-1 to 104-N such that it is readable and writable by each DTKV service. [0045]; In further embodiments, DTKV services 104-1 to 104-N are configured such they access/modify data log files 106-1 to 106-M in the context of file versions. [0058]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version);
determining whether the version number associated with the key-value pair included in the first message is equal to the stored version number associated with the key- value pair (Castellano: [0010]; The DTKV store can include a set of nodes and can execute, on each node, key-value operations (e.g., PUT, GET, DELETE, etc.) that enable users to store and retrieve data in the form of key-value pairs. [0014]; Upon receiving a user invocation of a particular operation, DTKV service 104-1 to 104-N can execute the operation and return a response (if appropriate) to the user. [0045]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version);
performing, in response to a determination that the version number associated with the key-value pair included in the first message is equal to the stored version number associated with the key-value pair (Castellano: [0058]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version),
the write operation and incrementing the stored version number associated with the key-value pair (Castellano: [0036]; Data log files 106-1 to 106-M store the actual key-value pairs maintained by DTKV store 100. Each data log file 106-1 to 106-M can be shared across DTKV services 104-1 to 104-N such that it is readable and writable by each DTKV service. [0058]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version);
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify SMITH (teaches receives from a client a message to perform a write operation associated with a key-value pair, wherein the message at least includes a key, a version number associated with the key-value pair) with the teachings of Castellano (teaches compares the version number associated with the key-value pair included in the message with a stored version number associated with the key-value pair, wherein the stored version number associated with the key-value pair is incremented each time a value is written to the key-value pair; determines whether the version number associated with the key-value pair included in the message is equal to the stored version number associated with the key-value pair; and performs the write operation and increments the stored version number associated with the key-value pair in response to a determination that the version number associated with the key-value pair included in the message is equal to the stored version number associated with the key-value pair). One of ordinary skill in the art would have been motivated to make such a combination of improving the scalability by utilizing lock modes and achieving a system that provide the particular target to achieve the system to obtaining the resource based on the scalability limit (See: Castellano [0067]). In addition, the references (SMITH and Castellano) teach features that are directed to analogous art and they are directed to the same field of endeavor as SMITH and Castellano are directed to utilizes key value management and providing data according to distributing.
Although, SMITH teaches select, according to a hashing algorithm, at least one secondary node of the plurality of nodes to which to replicate the key-value pair and generate a second message and third message to replicate the key-value pair to the at least one secondary node of the plurality of nodes and at least one tertiary node of the plurality of nodes (See SMITH: [0037]; For example, keys 312 may be hashed to generate an MD5 hash value, that randomly assigns a particular key 312 to one of the nodes 131 of the cluster 400. Cluster 400 may also be associated with a replication factor that ensures that data is stored redundantly such that a failure in one node does not stop requests to access the data store from being serviced by the cluster 400. For example, a replication factor of 3 reflects that data is stored on three nodes). The modification of SMITH and Castellano teaches claimed invention substantially as claimed, however the modification of SMITH and Castellano does not explicitly teach in response to incrementing the stored version number, replicate the key-value pair to at least one secondary node of the plurality of nodes; and in response to detecting a failure of the at least one secondary node, replicate the key-value pair to at least one tertiary node of the plurality of nodes; maintain multiple copies of location metadata indicating which of the plurality of nodes store the key-value pair; batch at least one of the second message or the third message with additional messages for sending to at least one of the secondary node of the plurality of nodes or the tertiary node of the plurality of nodes.
However, Merriman teaches in response to incrementing the stored version number, replicate the key-value pair to at least one secondary node of the plurality of nodes (Merriman: Col 35, lines 11-15; Each operation in the log can be associated with a time and an increasing value so that an order can be determined for each operation. In one example, a monotonically increasing to value is employed and associated with each operation. Each operation can also be time stamped. Col 63, lines 40-43; new data elements that are added receive a key value that is greater than any previously used key value. A simple example of such a key pattern includes a monotonically increasing key value. Col 35, lines 63-63; Replication from a primary to secondary nodes can include a commitment operation): and
in response to detecting a failure of the at least one secondary node, replicate the key-value pair to at least one tertiary node of the plurality of nodes (Merriman: Col 34, lines 47-52; For example, a node may be added or initialized into a set using a synchronization operation that causes the node to capture a complete copy of a database as it exists on another node. Once synchronization is complete, replication operations can proceed for that node. Col 36, lines 29-31; Secondary nodes, as well as the primary, can monitor communication status with other nodes to determine if a failure has occurred. Col 38, lines 22-24; Although automatic fail-over processing can result in lost data, an operation becomes durable once replicated across a majority of the nodes within the replica set. Col 58, lines 57-60; A replica set can be configured to perform asynchronous replication across a series of nodes);
maintain multiple copies of location metadata indicating which of the plurality of nodes store the key-value pair (Merriman: Col 48, lines 8-13; Metadata for the shard cluster can include, for example, information on the ranges of data stored in each partition, information associated with managing the shard cluster, partition counts, number of shard servers, data index information, partition size constraints, data distribution thresholds, among other options. Col 52, lines 27-31; The shard key ranges associated with a given partition can be used by the shard cluster (e.g. through a router process) to direct database requests to appropriate shard servers hosting the particular partition. Col 58, lines 62-64; By implementing each shard as a replica set, the shard cluster can provide for high availability and high consistency in the underlying data);
batch at least one of the second message or the third message with additional messages for sending to at least one of the secondary node of the plurality of nodes or the tertiary node of the plurality of nodes (Merriman: Col 30, lines 59-60; replicates changes to the database throughout the set of nodes asynchronously. Col 34, lines 59-64; The operations are then transmitted asynchronously from the primary node to its respective secondary nodes. In some settings , the secondary nodes are configured to periodically query the operation log of the primary node to determine any operations that should be retrieved and executed) {Examiner correlates the batching a second or third message with the additional message to the secondary or tertiary node of the plurality of nodes according to transmitting asynchronously to its respective secondary by periodically query any operations (receiving sets of message) that should be retrieved and to be executed to that secondary nodes));
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify SMITH (teaches receives from a client a message to perform a write operation associated with a key-value pair, wherein the message at least includes a key, a version number associated with the key-value pair) with the teachings of Castellano (teaches compares the version number associated with the key-value pair included in the message with a stored version number associated with the key-value pair, wherein the stored version number associated with the key-value pair is incremented each time a value is written to the key-value pair; determines whether the version number associated with the key-value pair included in the message is equal to the stored version number associated with the key-value pair; and performs the write operation and increments the stored version number associated with the key-value pair in response to a determination that the version number associated with the key-value pair included in the message is equal to the stored version number associated with the key-value pair) to further include Merriman (teaches in response to incrementing the stored version number, replicate the key-value pair to at least one secondary node of the plurality of nodes; and in response to detecting a failure of the at least one secondary node, replicate the key-value pair to at least one tertiary node of the plurality of nodes). One of ordinary skill in the art would have been motivated to make such a combination of improving mirroring data for high availability and disaster recovery to prevent data from being lost (See: Merriman: Col 22, lines 26-29)). In addition, the references (SMITH, Castellano, and Merriman) teach features that are directed to analogous art and they are directed to the same field of endeavor as SMITH, Castellano, and Merriman are directed to utilizes key value management and providing data according to distributing.
Regarding claim 20, SMITH teaches a computer program product, the computer program product being embodied in a non-transitory computer readable medium and comprising computer instructions for (SMITH: [0067]; The program(s) of the program product define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Such computer-readable storage media, when carrying computer-readable instructions that direct the functions of the present invention, are embodiments of the present invention):
receiving from a client a message to perform a write operation associated with a key- value pair, wherein the message at least includes a key, a version number associated with the key-value pair (SMITH: [0033]; Each row 311 in a column family 310 may define a number of different columns that represent various values associated with a particular key 312. [0037]; The node to which client computer 181 connects acts as a coordinator for requests transmitted by client computer 181 to read from or write to the data store. Each request is associated with a particular key 312 and a particular column family 310), and
a sequence number associated with the write operation (SMITH: [0032]-[0033]; As key-value pairs are added to the data store, a row 311 will be added to the column family 310. Columns (e.g., 313, 314, 315, etc.) within each column family 310 are associated with an identifier (e.g., a string) and a timestamp (e.g., 313-1, 314-1, 315-1, etc.). Each row 311 in a column family 310 may define a number of different columns that represent various values associated with a particular key 312. [0037]; Each request is associated with a particular key 312 and a particular column family 310);
select, according to a hashing algorithm, at least one secondary node of the plurality of nodes to which to replicate the key-value pair and generate a second message to replicate the key-value pair to the at least one secondary node of the plurality of nodes (SMITH: [0037]; For example, keys 312 may be hashed to generate an MD5 hash value, that randomly assigns a particular key 312 to one of the nodes 131 of the cluster 400. Cluster 400 may also be associated with a replication factor that ensures that data is stored redundantly such that a failure in one node does not stop requests to access the data store from being serviced by the cluster 400. For example, a replication factor of 3 reflects that data is stored on three nodes. [0042]; Application 520 is configured to store key-value pairs in the data store and perform backend operations to ensure that the data store is eventually-consistent across every node. As a request is received by a node, the request is added to a commit log 530, stored in storage device 128. The commit log 530 acts like a buffer that allows requests to be processed asynchronously from when the requests arrive at the node);
select, according to the hashing algorithm, at least one tertiary node of the plurality of nodes and generate a third message to replicate the key-value pair to the at least one tertiary node of the plurality of nodes (SMITH: [0037]; For example, keys 312 may be hashed to generate an MD5 hash value, that randomly assigns a particular key 312 to one of the nodes 131 of the cluster 400. Cluster 400 may also be associated with a replication factor that ensures that data is stored redundantly such that a failure in one node does not stop requests to access the data store from being serviced by the cluster 400. For example, a replication factor of 3 reflects that data is stored on three nodes. [0042]; Application 520 is configured to store key-value pairs in the data store and perform backend operations to ensure that the data store is eventually-consistent across every node. As a request is received by a node, the request is added to a commit log 530, stored in storage device 128. The commit log 530 acts like a buffer that allows requests to be processed asynchronously from when the requests arrive at the node);
SMITH does not explicitly teach in response to receiving the first message: compare the version number associated with the key-value pair included in the first message with a stored version number associated with the key- value pair, wherein the stored version number associated with the key-value pair is incremented each time a value is written to the key-value pair; determine whether the version number associated with the key- value pair included in the first message is equal to the stored version number associated with the key-value pair; and perform, in response to a determination that the version number associated with the key-value pair included in the first message is equal to the stored version number associated with the key-value pair, the write operation and increment the stored version number associated with the key-value pair;
However, Castellano teaches in response to receiving the first message: comparing the version number associated with the key-value pair included in the first message with a stored version number associated with the key-value pair, wherein the stored version number associated with the key-value pair is incremented each time a value is written to the key-value pair (Castellano: [0014]; Upon receiving a user invocation of a particular operation, DTKV service 104-1 to 104-N can execute the operation and return a response (if appropriate) to the user. [0036]; Data log files 106-1 to 106-M store the actual key-value pairs maintained by DTKV store 100. Each data log file 106-1 to 106-M can be shared across DTKV services 104-1 to 104-N such that it is readable and writable by each DTKV service. [0045]; In further embodiments, DTKV services 104-1 to 104-N are configured such they access/modify data log files 106-1 to 106-M in the context of file versions. [0058]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version);
determining whether the version number associated with the key-value pair included in the first message is equal to the stored version number associated with the key- value pair (Castellano: [0010]; The DTKV store can include a set of nodes and can execute, on each node, key-value operations (e.g., PUT, GET, DELETE, etc.) that enable users to store and retrieve data in the form of key-value pairs. [0014]; Upon receiving a user invocation of a particular operation, DTKV service 104-1 to 104-N can execute the operation and return a response (if appropriate) to the user. [0045]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version);
performing, in response to a determination that the version number associated with the key-value pair included in the first message is equal to the stored version number associated with the key-value pair (Castellano: [0058]; In other words, each data log file 106-1 to 106-M is associated with a version number, and DTKV services 104-1 to 104-N specify a version number when accessing a data log file, as well as increment a data log file's version number when modifying the data log file. [0058]; (3) Append(file, in Version)—Appends data to the end of the specified file, if and only if the current version number of the file matches the value of the parameter in Version),
the write operation and incrementing the stored version number associated with the key-value pair (Castellano: [0036]; Data log files 106-1 to 106-M store the actual key-value pairs maintained by DTKV store 100. Each data log file 106-1 to 106-M can be shared across DTKV services 104-1 to 104-N such that it is readable and writable by each