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 .
DETAILED ACTION
The Action is responsive to the Amendments and Remarks filed on 11/18/2025. Claims 1-4 and 6-22 are pending claims. Claims 1 and 20 are written in independent form. Claim 5 has been cancelled by Applicant. Claims 21-22 are new claims.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-4 and 6-22 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by VanBenschoten et al. (U.S. Pre-Grant Publication No. 2023/0021150, hereinafter referred to as VanBenschoten).
Regarding Claim 1:
VanBenschoten teaches a computer-implemented method for controlling execution of conflicting transactional operations, the method comprising:
Receiving, from a client device by a computing node of a plurality of computing nodes, a first transaction comprising
VanBenschoten teaches “a node may receive a read transaction from a client device. A node may receive a write transaction from a client device” (Para. [0037]).
VanBenschoten further teaches a plurality of computing nodes by teaching ““Node” generally refers to an individual computing device that is a part of a cluster. A node may join with one or more other nodes to form a cluster. One or nodes that comprise a cluster may store data (e.g., tables, indexes, etc.) in a map of key-value pairs.” (Para. [0026]).
(i) a first request directed to first data of a first partition stored by the plurality of computing nodes and (ii) a first timestamp,
VanBenschoten teaches “receiving a read transaction at a fourth time, wherein the read transaction is directed to the partition” (Para. [0010]).
wherein a refresh span list is configured to record an indication of a version of data read by the first transaction during execution of the first transaction;
It is noted that the language recites the refresh span list being “configured to record…during execution” which is understood as having the ability to record during execution, but no execution or recording step is actively recited in at least the independent claims.
VanBenschoten teaches “For a transaction, the gateway node (e.g., the node that initially receives a transaction) may determine a timestamp for the transaction based on HLC time for the node. The transaction layer may enable transaction timestamps based on HLC time. A timestamp within the cluster may be used to track versions of KVs (e.g., through MVCC as to be described herein) and provide guaranteed transactional isolation.” (Para. [0055]) and “the transaction layer may store the operation's timestamp in a timestamp cache. The timestamp cache may include the transaction having the latest timestamp (i.e. the furthest ahead in time) for value(s) read by the transaction.” (Para. [0058]).VanBenschoten further teaches “the storage layer may use MVCC to enable concurrent requests. In some cases, the use of MVCC by the storage layer may guarantee consistency for the cluster. As described herein, HLC timestamp may be used to differentiate between different versions of data by tracking commit timestamps for data” (Para. [0105]).
identifying, based on the first data being associated with a second timestamp greater than the first timestamp, a conflict associated with the first transaction;
VanBenschoten teaches identifying that “the latest time of the timestamp cache” is greater than “the timestamp of the write transaction” thus identifying a conflict associated with the write transaction and “the transaction layer may attempt to advance the timestamp of the write transaction forward to a later time” (Para. [0058]).
determining, based on the conflict, a refresh timestamp greater than or equal to the second timestamp; and
VanBenschoten teaches identifying that “the latest time of the timestamp cache” is greater than “the timestamp of the write transaction” thus identifying a conflict associated with the write transaction and “the transaction layer may attempt to advance the timestamp of the write transaction forward to a later time” (Para. [0058]).
VanBenschoten further teaches “the transaction layer may allow for one or more conflict types, where a conflict type may result from a transaction encountering and/or otherwise interacting with a write intent at a key” (Para. [0071]) and “the transaction layer may allow for one or more additional conflict types that do not involve write intents” and “advance the timestamp of the read transaction past the timestamp of the KV according to read refreshing” (Para. [0072]) thereby teaching determining a refresh timestamp that is “past the timestamp of the KV according to read refreshing”.
committing, based on the refresh span list, the first transaction at the refresh timestamp.
VanBenschoten teaches “ If the check succeeds (e.g., write transactions have not occurred between the original transaction timestamp and the advanced transaction timestamp), the transaction may be allowed to commit.” (Para. [0074]).
Regarding Claim 2:
VanBenschoten further teaches:
wherein the computing node
(i) assigns the first timestamp to the first transaction and
VanBenschoten teaches “monitoring a clock during the execution of the one or more operations of the write transaction, wherein the first time and the second time are derived from the clock” (Para. [0010]) where “a first time indicated by a clock corresponding to the database node” (Claim 1).
(ii) generates the refresh span list based on receiving the first transaction, and
VanBenschoten teaches “For a transaction, the gateway node (e.g., the node that initially receives a transaction) may determine a timestamp for the transaction based on HLC time for the node. The transaction layer may enable transaction timestamps based on HLC time. A timestamp within the cluster may be used to track versions of KVs (e.g., through MVCC as to be described herein) and provide guaranteed transactional isolation.” (Para. [0055]).
wherein the first timestamp is equal to a time at which the computing node received the first transaction.
VanBenschoten teaches “monitoring a clock during the execution of the one or more operations of the write transaction, wherein the first time and the second time are derived from the clock” (Para. [0010]) where “a first time indicated by a clock corresponding to the database node” (Claim 1).
Regarding Claim 3:
VanBenschoten further teaches:
wherein the first request is configured to read a most recent version of the first data having a timestamp less than or equal to the first timestamp.
VanBenschoten teaches “A timestamp cache may track the highest timestamp (i.e., most recent) for any read operation that a given range has served” (Para. [0113]).
Regarding Claim 4:
VanBenschoten further teaches:
wherein the first request is configured to write a new version of the first data having the first timestamp.
VanBenschoten teaches “For a transaction, the gateway node (e.g., the node that initially receives a transaction) may determine a timestamp for the transaction based on HLC time for the node. The transaction layer may enable transaction timestamps based on HLC time. A timestamp within the cluster may be used to track versions of KVs (e.g., through MVCC as to be described herein) and provide guaranteed transactional isolation.” (Para. [0055]) thereby teaching writing new versions and using multi-version concurrency control to allow access to and modification of data concurrently.
Regarding Claim 6:
VanBenschoten further teaches:
wherein
(i) the first data comprises key-value data and
VanBenschoten teaches “the transaction layer may check for newer (e.g., more recent) committed values at the KVs of the range on which the write transaction is operating. If newer committed values exist at the KVs of the range, the write transaction may be restarted. Alternately, if the write transaction identifies write intents at the KVs of the range, the write transaction may be resolved as a transaction conflict as to be described herein.” (Para. [0050])
(ii) the first partition comprises a plurality of versions of the key-value data.
VanBenschoten teaches “ for read transactions, the transaction layer may execute a read transaction at KVs of a range indicated by the read transaction. The transaction layer may execute the read transaction if the read transaction is not aborted. The read transaction may read multi-version concurrency control (MVCC) values at the KVs of the range as to be described herein in “Storage Layer”. Alternately, the read transaction may read write intents at the KVs, such that the read transaction may be resolved as a transaction conflict as to be described herein.” (Para. [0051]).
VanBenschoten further teaches “Isolation for requests and/or transactions may be accomplished by maintaining multiple versions and/or by allowing requests to acquire locks” (Para. [0067]).
Regarding Claim 7:
VanBenschoten further teaches:
Wherein the first transaction comprises a second request configured to read a most recent version of second data of a second partition stored by the plurality of computing nodes,
VanBenschoten teaches “A transaction may be composed of one or more requests.” (Para. [0067]) where
The most recent version of the second data having a timestamp less than or equal to the first timestamp,
VanBenschoten teaches “A timestamp cache may track the highest timestamp (i.e., most recent) for any read operation that a given range has served” (Para. [0113]).
Wherein the first request is configured to write a new version of the first data having the first timestamp,
VanBenschoten teaches “ the transaction layer may allow for one or more conflict types, where a conflict type may result from a transaction encountering and/or otherwise interacting with a write intent at a key. A write/write conflict may occur when two pending transactions create write intents for the same key. A write/read conflict may occur when a read transaction encounters an existing write intent with a timestamp less than the timestamp of the read transaction.” (Para. [0071]).
VanBenschoten further teaches “For a transaction, the gateway node (e.g., the node that initially receives a transaction) may determine a timestamp for the transaction based on HLC time for the node. The transaction layer may enable transaction timestamps based on HLC time. A timestamp within the cluster may be used to track versions of KVs (e.g., through MVCC as to be described herein) and provide guaranteed transactional isolation.” (Para. [0055]) thereby teaching writing new versions and using multi-version concurrency control to allow access to and modification of data concurrently.
Wherein identifying the conflict associated with the first transaction comprises:
Determining the first data was written at the second timestamp;
VanBenschoten teaches “ write/write conflict may occur when two pending transactions create write intents for the same key” (Para. [0071]) thereby teaching that data causing conflict can be written or read at the second timestamp
Comparing the first timestamp to the second timestamp;
VanBenschoten teaches comparing the timestamps by teaching that “the latest time of the timestamp cache” is greater than “the timestamp of the write transaction” (Para. [0058]).
Based on the second timestamp being greater than the first timestamp, identifying the conflict; and
VanBenschoten teaches identifying that “the latest time of the timestamp cache” is greater than “the timestamp of the write transaction” thus identifying a conflict associated with the write transaction and “the transaction layer may attempt to advance the timestamp of the write transaction forward to a later time” (Para. [0058]).
Determining, based on identifying the conflict, the refresh timestamp is greater than or equal to the second timestamp.
VanBenschoten teaches identifying that “the latest time of the timestamp cache” is greater than “the timestamp of the write transaction” thus identifying a conflict associated with the write transaction and “the transaction layer may attempt to advance the timestamp of the write transaction forward to a later time” (Para. [0058]).
VanBenschoten further teaches “the transaction layer may allow for one or more conflict types, where a conflict type may result from a transaction encountering and/or otherwise interacting with a write intent at a key” (Para. [0071]) and “the transaction layer may allow for one or more additional conflict types that do not involve write intents” and “advance the timestamp of the read transaction past the timestamp of the KV according to read refreshing” (Para. [0072]) thereby teaching determining a refresh timestamp that is “past the timestamp of the KV according to read refreshing”.
Regarding Claim 8:
Some of the limitations herein are similar to some or all of the limitations of Claim 7.
VanBenschoten further teaches:
Wherein identifying the conflict associated with the first transaction comprises:
Determining the first data was read by a second transaction at the second timestamp;
VanBenschoten teaches “A write/read conflict may occur when a read transaction encounters an existing write intent with a timestamp less than the timestamp of the read transaction” (Para. [0071]) thereby teaching that data causing conflict can be written or read at the second timestamp.VanBenschoten also teaches “the transaction layer may allow for one or more additional conflict types that do not involve write intents. A write after read conflict may occur when a write transaction having a lower timestamp conflicts with a read transaction having a higher timestamp.” (Para.[0072]).
Regarding Claim 9:
VanBenschoten further teaches:
Wherein a timestamp data structure indicates the first data was read by the second transaction data at the second timestamp.
VanBenschoten teaches “A write/read conflict may occur when a read transaction encounters an existing write intent with a timestamp less than the timestamp of the read transaction” (Para. [0071])
Regarding Claim 10:
Some of the limitations herein are similar to some or all of the limitations of Claim 7.
VanBenschoten further teaches:
Wherein identifying the conflict associated with the first transaction comprises:
Wherein the new version of the first data is uncommitted;
VanBenschoten teaches “Values may be written in a provisional (i.e. uncommitted) state known as a write intent.” (Para. [0061])
Identifying, by a second transaction, the first timestamp of the new version of the first data, wherein the second transaction comprises a third request configured to read a most recent version of the first data having a fourth timestamp less than or equal to the second timestamp;
VanBenschoten teaches “Values may be written in a provisional (i.e. uncommitted) state known as a write intent.” (Para. [0061]) where “ the transaction layer may allow for one or more conflict types, where a conflict type may result from a transaction encountering and/or otherwise interacting with a write intent at a key. A write/write conflict may occur when two pending transactions create write intents for the same key. A write/read conflict may occur when a read transaction encounters an existing write intent with a timestamp less than the timestamp of the read transaction.” (Para. [0071])
Regarding Claim 11:
VanBenschoten further teaches:
Wherein the first request is configured to read a most recent version of the first data having a timestamp less than or equal to the first timestamp,
VanBenschoten teaches “receiving a read transaction at a fourth time, wherein the read transaction is directed to the partition, and wherein the fourth time is before the synthetic timestamp.” (Para. [0010])
Wherein identifying the conflict associated with the first transaction comprises:
Determining a version of the first data has the second timestamp;
VanBenschoten teaches “sending, from the leader replica to the zero or more follower replicas, a closed timestamp update comprising the synthetic timestamp, wherein the zero or more follower replicas are each configured to serve a read transaction prior to the synthetic timestamp” (Para. [0010])
Determining the second timestamp is (i) greater than the first timestamp and (ii) within an uncertainty interval of the first transaction;
VanBenschoten teaches “receiving a read transaction at a fourth time, wherein the read transaction is directed to the partition, and wherein the fourth time is before the synthetic timestamp” (Para. [0010]).
Based on the second timestamp being (i) greater than the first timestamp and (ii) within the uncertainty interval of the first transaction, identifying the conflict; and
VanBenschoten teaches “receiving a read transaction at a fourth time, wherein the read transaction is directed to the partition, and wherein the fourth time is before the synthetic timestamp” and “updating the fourth time to a fifth time based on determining the synthetic timestamp to be within an uncertainty interval, wherein the fifth time is after the synthetic timestamp, and wherein the uncertainty interval is configured based on the fourth time and a maximum clock offset; “ (Para. [0010]).
Determining, based on identifying the conflict, the refresh timestamp is greater than or equal to the second timestamp.
VanBenschoten teaches “The method can further include updating the fourth time to a fifth time based on determining the synthetic timestamp to be within an uncertainty interval, wherein the fifth time is after the synthetic timestamp, and wherein the uncertainty interval is configured based on the fourth time and a maximum clock offset; and serving, from a replica of the one or more replicas, the read transaction at the fifth time.” (Para. [0010])
Regarding Claim 12:
VanBenschoten further teaches:
Wherein the uncertainty level is configured based on a maximum allowed timestamp difference between a plurality of clocks operated by the plurality of computing nodes.
VanBenschoten teaches “A maximum allowed offset may be the maximum allowed timestamp difference between nodes of the cluster.” (Para. [0057]).
Regarding Claim 13:
VanBenschoten further teaches:
causing communication, based on determining the refresh timestamp, between two or more computing nodes of the plurality of computing nodes using at least one refresh request comprising an indication of third data of a third partition stored by the plurality of computing nodes, wherein the first transaction previously read a most recent version of the third data having a third timestamp less than or equal to the first timestamp;
VanBenschoten teaches “Considerations may include checking KVs previously read by the transaction to verify that other write transactions have not occurred at the KVs between the original transaction timestamp and the advanced transaction timestamp.” (Para. [0074])
VanBenschoten further teaches the communication between computing nodes of the plurality of computing nodes by teaching “the transaction layer may enable transaction pipelining” and “transaction pipelining may include one or more operations. In transaction pipelining, for each statement, the gateway node corresponding to the transaction may communicate with the leaseholders (L1, L2, L3, . . . , Li) for the ranges indicated by the transaction. Each leaseholder Li may receive the communication from the gateway node and may perform one or more operations in parallel. Each leaseholder Li may create write intents and may send the write intents to corresponding follower nodes for the leaseholder Li. Each Li may respond to the gateway node that the write intents have been sent.” (Para. [0075])
Determining, based on the at least one refresh request, each version of the third data comprises a respective timestamp that is (i) less than or equal to the first timestamp or (ii) greater than the refresh timestamp; and
VanBenschoten teaches “A timestamp cache may track the highest timestamp (i.e., most recent) for any read operation that a given range has served” (Para. [0113]).
Updating the first timestamp to be equal to the refresh timestamp based on determining each version of the third data comprises a respective timestamp that is (i) less than or equal to the first timestamp or (ii) greater than the refresh timestamp.
VanBenschoten teaches “The check may be executed by tracking each read using a Refresh Request (RR). If the check succeeds (e.g., write transactions have not occurred between the original transaction timestamp and the advanced transaction timestamp), the transaction may be allowed to commit.” (Para. [0074]).
Regarding Claim 14:
VanBenschoten further teaches:
Committing, based on updating the first timestamp to be equal to the refresh timestamp, the first transaction at the refresh timestamp.
VanBenschoten teaches “The check may be executed by tracking each read using a Refresh Request (RR). If the check succeeds (e.g., write transactions have not occurred between the original transaction timestamp and the advanced transaction timestamp), the transaction may be allowed to commit.” (Para. [0074]).
Regarding Claim 15:
VanBenschoten further teaches:
Wherein the first request comprises an indicator comprising a value that is selected (i) based on the refresh span list and (ii) by the computing node, and
VanBenschoten teaches “the DistSender of the gateway node may aggregate read values for each read operation included in the Batch Request. Based on completion of the operations of the Batch Request, the DistSender may record the success of each transaction in a corresponding transaction record. To record the success of a transaction, the DistSender may check the timestamp cache of the range where the first write transaction occurred to determine whether the timestamp for the write transaction was advanced. If the timestamp was advanced, the transaction may perform a read refresh to determine whether values associated with the transaction had changed. If the read refresh is successful (e.g., no values associated with the transaction had changed), the transaction may commit at the advanced timestamp. If the read refresh fails (e.g., at least some value associated with the transaction had changed), the transaction may be restarted” (Para.[0116]).
Further comprising:
Updating, based on determining the refresh timestamp and the value of the indicator, the first timestamp to be equal to the refresh timestamp.
VanBenschoten teaches “the DistSender of the gateway node may aggregate read values for each read operation included in the Batch Request. Based on completion of the operations of the Batch Request, the DistSender may record the success of each transaction in a corresponding transaction record. To record the success of a transaction, the DistSender may check the timestamp cache of the range where the first write transaction occurred to determine whether the timestamp for the write transaction was advanced. If the timestamp was advanced, the transaction may perform a read refresh to determine whether values associated with the transaction had changed. If the read refresh is successful (e.g., no values associated with the transaction had changed), the transaction may commit at the advanced timestamp. If the read refresh fails (e.g., at least some value associated with the transaction had changed), the transaction may be restarted” (Para.[0116]). Therefore, VanBenschoten teaches based on the value of the indicator of transaction changes, committing the transaction at the advanced timestamp.
Regarding Claim 16:
All of the limitations herein are similar to some or all of the limitations of Claim 14.
Regarding Claim 17:
VanBenschoten further teaches:
Wherein (i) the indicator has a first value when the refresh span list indicates the first transaction has executed at least one read request, and
VanBenschoten teaches “the DistSender of the gateway node may aggregate read values for each read operation included in the Batch Request. Based on completion of the operations of the Batch Request, the DistSender may record the success of each transaction in a corresponding transaction record. To record the success of a transaction, the DistSender may check the timestamp cache of the range where the first write transaction occurred to determine whether the timestamp for the write transaction was advanced. If the timestamp was advanced, the transaction may perform a read refresh to determine whether values associated with the transaction had changed. If the read refresh is successful (e.g., no values associated with the transaction had changed), the transaction may commit at the advanced timestamp. If the read refresh fails (e.g., at least some value associated with the transaction had changed), the transaction may be restarted” (Para.[0116])
(ii) the indicator has a second value when the refresh span list indicates the first transaction has not executed any read request, and
VanBenschoten teaches “the DistSender of the gateway node may aggregate read values for each read operation included in the Batch Request. Based on completion of the operations of the Batch Request, the DistSender may record the success of each transaction in a corresponding transaction record. To record the success of a transaction, the DistSender may check the timestamp cache of the range where the first write transaction occurred to determine whether the timestamp for the write transaction was advanced. If the timestamp was advanced, the transaction may perform a read refresh to determine whether values associated with the transaction had changed. If the read refresh is successful (e.g., no values associated with the transaction had changed), the transaction may commit at the advanced timestamp. If the read refresh fails (e.g., at least some value associated with the transaction had changed), the transaction may be restarted” (Para.[0116])
Wherein updating the first timestamp to be equal to the refresh timestamp further comprises:
Determining the indicator has the second value; and
VanBenschoten teaches “the DistSender of the gateway node may aggregate read values for each read operation included in the Batch Request. Based on completion of the operations of the Batch Request, the DistSender may record the success of each transaction in a corresponding transaction record. To record the success of a transaction, the DistSender may check the timestamp cache of the range where the first write transaction occurred to determine whether the timestamp for the write transaction was advanced. If the timestamp was advanced, the transaction may perform a read refresh to determine whether values associated with the transaction had changed. If the read refresh is successful (e.g., no values associated with the transaction had changed), the transaction may commit at the advanced timestamp. If the read refresh fails (e.g., at least some value associated with the transaction had changed), the transaction may be restarted” (Para. [0116])
Updating, based on determining the refresh timestamp and determining the indicator has the second value, the first timestamp to be equal to the refresh timestamp.
VanBenschoten teaches “The check may be executed by tracking each read using a Refresh Request (RR). If the check succeeds (e.g., write transactions have not occurred between the original transaction timestamp and the advanced transaction timestamp), the transaction may be allowed to commit.” (Para. [0074]).
Regarding Claim 18:
VanBenschoten further teaches:
Wherein committing the first transaction comprises reading a most recent version of the first data having a timestamp less than or equal to the refresh timestamp.
VanBenschoten teaches “a non-blocking transaction may perform locking such that contending read transactions may not be required to wait on the locks (e.g., the write intents) of the non-blocking transaction. In an example, the values written by a non-blocking write transaction may be committed with write intents resolved by the time that a read transaction attempts to read the values of the keys written by the non-blocking write transaction. In some cases, as described herein, a read transaction that observes write intents would need to determine the status of the write transaction via the transaction record, which may cause the read transaction to wait for the write intents to be resolved (e.g., committed, aborted, etc.)” (Para. [0126]).
Regarding Claim 19:
VanBenschoten further teaches:
Wherein (i) the first request is configured to write a new version of the first data, and (ii) committing the first transaction comprises writing the new version of the first data having the refresh timestamp.
VanBenschoten teaches “For a transaction, the gateway node (e.g., the node that initially receives a transaction) may determine a timestamp for the transaction based on HLC time for the node. The transaction layer may enable transaction timestamps based on HLC time. A timestamp within the cluster may be used to track versions of KVs (e.g., through MVCC as to be described herein) and provide guaranteed transactional isolation.” (Para. [0055]) thereby teaching writing new versions and using multi-version concurrency control to allow access to and modification of data concurrently.
VanBenschoten further teaches “ If the check succeeds (e.g., write transactions have not occurred between the original transaction timestamp and the advanced transaction timestamp), the transaction may be allowed to commit.” (Para. [0074]).
Regarding Claim 20:
Some of the limitations herein are similar to some or all of the limitations of Claim 1.
VanBenschoten further teaches a system comprising:
One or more computing nodes of a plurality of computing nodes, the one or more computing nodes configured to perform operations.
VanBenschoten further teaches a plurality of computing nodes by teaching ““Node” generally refers to an individual computing device that is a part of a cluster. A node may join with one or more other nodes to form a cluster. One or nodes that comprise a cluster may store data (e.g., tables, indexes, etc.) in a map of key-value pairs.” (Para. [0026]).
Regarding Claim 21:
Vanbenschoten further teaches:
Wherein the indication of the third data comprises an indication of a key or key span of the third partition, and
Vanbenschoten teaches “A transaction coordinator may be created by the transaction layer to manage the state of the write transaction. The client device may issue a write to a key “Alpha” of a range… The client device may issue a write to a key “Beta” of the range as a part of the same write transaction as the write to the “Alpha” key.” (Para. [0077]) where “A range may be a partition of a table, where a table may comprise one or more ranges” (Para. [0002]).
Wherein the at least one refresh request comprises (i) the indication of the key or the key span of the third partition, (ii) the refresh timestamp, and (iii) a refresh from the timestamp equal to the first timestamp.
VanBenschoten teaches “A transaction coordinator may be created by the transaction layer to manage the state of the write transaction. The client device may issue a write to a key “Alpha” of a range. The transaction coordinator may generate a write intent on the “Alpha” key where the data from the write will be written. The write intent may include a timestamp and a pointer to a currently nonexistent transaction record for the write. Each write intent in the write transaction may be assigned a unique sequence number. The unique sequence number may uniquely identify the write intent. The client device may issue a write to a key “Beta” of the range as a part of the same write transaction as the write to the “Alpha” key. The transaction coordinator may generate a write intent on the “Beta” key where the data from the write transaction will be written. The write intent may include a timestamp and a pointer to the same nonexistent transaction record as for the “Alpha” key, based on each write intent being a part of the same transaction. The client device may issue a request to commit the writes for the write transaction.” (Para. [0077])
Regarding Claim 22:
VanBenschoten further teaches:
Wherein the indication of the version of the data read by the first transaction comprises an indication of at least one key or key span of one or more partitions read by the first transaction during execution of the first transaction, and
VanBenschoten teaches “A range may be a partition of a table” (Para. [0002]) and “a latch manager may sequence incoming requests and may provide isolation between those requests. The latch manager may sequence and provide isolation to requests under the supervision of the concurrency manager. A latch manager may operate as follows. As write requests occur for a range, a leaseholder of the range may serialize write requests for the range. “ and “In some cases, read requests may generate latches. Multiple read latches over the same keys may be held concurrently.” (Para. [0069) thereby teaching an indication for data read comprising an indication of a key for at least one key of a range/partition during execution of the transaction.
Wherein the plurality of computing nodes store the one or more partitions.
VanBenschoten teaches “In some cases, relational databases can apply replication to ensure data survivability, where data is replicated among one or more computing devices (“nodes”) of a group of computing devices (“cluster”). A relational database may store data within one or more ranges, where a range is comprised of one or more key-value pairs and is replicated among one or more nodes of the cluster. A range may be a partition of a table, where a table may comprise one or more ranges. In some cases, multiple data table configurations may be used to optimally serve range data to client devices. Data tables can be configured based on the usage of the stored data and whether the data is frequently read and/or written by client devices.” (Para. [0002])
Response to Amendment
Applicant’s Amendments, filed on 11/18/2025, are acknowledged and accepted.
In light of Applicant’s Amendments filed on 11/18/2025, the claim objection to claims 7, 8, 10 has been withdrawn.
Response to Arguments
On pages 9-10 of the Remarks filed on 3/24/2025, Applicant argues that “Applicant respectfully submits that VanBenschoten fails to describe, teach, or suggest at least ‘wherein a refresh span list is configured to record an indication of a version of data read by the first transaction during execution of the first transaction.’ Rather, VanBenschoten's timestamp cache is described as tracking the highest timestamp (i.e., most recent) for any read operation that a given range has served so that a comparison may ensure that the write operation has a higher timestamp than the timestamp cache. VanBenschoten therefore describes a timestamp cache being used to track a highest timestamp for a read operation that a given range has served, and does not describe such a time stamp cache as being configured to ‘record an indication of a version of data read by the first transaction during execution of the first transaction’ as presently recite in claim 1. While VanBenschoten does generally describe ‘[a] timestamp within the cluster may be used to track versions of KVs,’ VanBenschoten appears to use the timestamp cache to track a highest timestamp for a read operation, rather than any indication of a version of data read by a transaction.”Applicant’s argument is not convincing because upon further review, VonBenschoten teaches ““the storage layer may use MVCC to enable concurrent requests. In some cases, the use of MVCC by the storage layer may guarantee consistency for the cluster. As described herein, HLC timestamp may be used to differentiate between different versions of data by tracking commit timestamps for data” (Para. [0105])” which by differentiating “between different versions of data” VonBenschoten is teaching not just the highest timestamp/version, but maintaining indications of multiple versions of data.
On page 10 of the Remarks filed on 3/24/2025, Applicant argues that “VanBenschoten fails to describe, teach, or suggest at least ‘wherein the at least one refresh request comprises (i) the indication of the key or the key span of the third partition, (ii) the refresh timestamp, and (iii) a refresh from timestamp equal to the first timestamp.’ While VanBenschoten does describe ‘[t]he check may be executed by tracking each read using a Refresh Request (RR),’ VanBenschoten is silent regarding such a Refresh Request comprising ‘(i) indication of the key or the key span of the third partition, (ii) the refresh timestamp, and (iii) a refresh from timestamp equal to the first timestamp" as recited in dependent claim 21.’.Applicant’s arguments related to the new limitations of Dependent Claim 21 have been considered but were not found to be persuasive in overcoming the previously cited prior art. The new limitations have been addressed in full in the rejection above.
On pages 10-11 of the Remarks filed on 3/24/2025, Applicant argues that “VanBenschoten fails to describe, teach, or suggest at least ‘wherein the indication of the version of data read by the first transaction comprises an indication of at least one key or key span of one or more partitions read by the first transaction during execution of the first transaction.’ As described above with respect to amended claim 1, VanBenschoten describes a timestamp cache as tracking the highest timestamp (i.e., most recent) for any read operation that a given range has served. However, VanBenschoten is silent regarding its timestamp cache being configured to record ‘an indication of at least one key or key span of one or more partitions read by the first transaction during execution of the first transaction’ as recited in dependent claim 22.”
Applicant’s arguments related to the new limitations of Dependent Claim 22 have been considered but were not found to be persuasive in overcoming the previously cited prior art. The new limitations have been addressed in full in the rejection above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Feng et al. (U.S. Pre-Grant Publication No. 2023/0106118) teaches processing a sequence of transactions to maintain consistency in a distributed system. A node receives a first transaction from a client for a data record associated with a first timestamp. The node identifies a second transaction for the data record that conflicts with the first transaction, where the identified second transaction has a second timestamp that is a most recent transaction stored in the node. A determination is then received by the node of a transmission status of the second transaction, and a result of the first transaction is transmitted to fulfill the first transaction received from a client based on the determined transmission status, fulfillment of the first transaction occurring after a full transmission time period of the first transaction is greater than or equal to a minimum transaction latency (MTL) of the distributed system.
Grabham et al. (U.S. Patent No. 11,334,552) teaches providing a redundancy tool for performing transactions. A transaction to be performed on a data stored in a database may be received. A timestamp may be assigned to the transaction. A lock may be assigned on the timestamp. The transaction may be performed on the data. The lock may be refreshed while performing the transaction on the data. A validity of the lock may be checked at after performing the transaction on the data. Responsive to the lock being valid, a result of performing the transaction on the data may be committed.
Werner et al. (U.S. Pre-Grant Publication No. 2023/0081900) teaches executing transactional schema changes at a database are provided. The method includes receiving, at a gateway node of a cluster of database nodes, a statement corresponding to a schema of a database stored by the cluster, wherein a parent transaction comprises the statement, the statement comprises a schema change operation to modify the schema, and a first version of one or more versions of a descriptor comprises the schema. The method includes generating, by the parent transaction and using one or more child transactions, a version of a synthetic descriptor comprising an updated schema with an added schema element configured to be available for the parent transaction. The method includes writing the synthetic descriptor as an updated version of the descriptor, wherein the updated version comprises the updated schema with the added schema element in a publicly available state. The method includes committing the parent transaction.The reference further teaches “ to ensure that an ongoing (e.g., non-committed) constraint change operation of a transactional schema change will not be violated by a concurrent write operation, the concurrent write operation may transparently prevent the transactional schema change from being applied in order to avoid leaking the existence of the uncommitted schema change to the user. In some embodiments, the concurrent writer may prevent the transactional schema change from being applied by writing to a key span which the transactional schema change previously read. Because the schema change transaction executes using serializable isolation, a write to a key span which the schema change transaction read before its final commit timestamp will prevent the schema change transaction from committing. The key span may be included in a constraint coordination table. In some embodiments, before committing, the schema change may attempt to delete all entries in the constraint coordination span. Based on the schema change transaction previously determining that the key span was empty, if it now discovers any rows to be deleted, the schema change transaction may abort. In some cases, the values being written to the key span by the concurrent write transaction may be empty values to avoid any need for garbage collection for the key span. The empty values may include a time stamp and the corresponding key of the key span.” (Para. [0213])
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 ROBERT F MAY whose telephone number is (571)272-3195. The examiner can normally be reached Monday-Friday 9:30am to 6pm.
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, Boris Gorney can be reached on 571-270-5626. 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.
/ROBERT F MAY/Examiner, Art Unit 2154 2/3/2026
/BORIS GORNEY/Supervisory Patent Examiner, Art Unit 2154