Response to Amendment
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to amendment and RCE filed on 6/1/26. Claims 34 and 46 are cancelled and new claims 51 and 52 are submitted, based on claim 31, 38 and 39, respectively. Claims 31-33, 35-45 and 47-52 are now pending.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 31-33, 35-45 and 47-52 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-28 of U.S. Patent No. 11,860,860. Although the claims at issue are not identical, they are not patentably distinct from each other because they claim the same subject matter using broader terminology.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 31-33, 35-45 and 47-52 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hsieh et al (USPN. 10,783,133).
31 and 43. A computer-implemented system and method, comprising a processor and memory, comprising (figs. 1 and 3):
receiving a write transaction, wherein the write transaction is configured to write to data of two or more replicas of a partition stored by two or more database nodes (figs. 1, 3 and 6, item 615, 670 and 680, and col. 13, lines 31-42, transactions received such as write transaction, and the write transaction is broadcasted to replicas);
generating and associating, at a first database node of the plurality of database nodes, a synthetic timestamp with the write transaction, wherein the synthetic timestamp leads a first timestamp by a non-blocking duration, the first timestamp corresponding to a present time indicated by a clock corresponding to the first database node and wherein the non-blocking duration is determined as a function of (i) a latency between a pair of database nodes of the plurality of database nodes and (ii) a maximum clock offset between any pair of clocks of the plurality of database nodes (fig. 6, items 620 and 670, col. 12 lines 64-67, and col. 13, lines 1-6 and 23-31, timestamp created/selected by a replication leader and time-interval based on lease which extends a base timestamp, and item 680, associate with the write node/transaction, and
cols. 9-10, lines 39-3, time synch deamon calculate offset intervals for different locations of timestamps using clock synchronization for acceptable and functioning time masters, note that sets of timemaster offsets are validated against each other, wherein the method “employ an agreement algorithm to detect and reject offsets from malfunctioning time master”, and col. 13, lines 15-31 “timestamp” may be verified to ensure that it falls within the time lease reserved in block 610);
executing, based on generating the synthetic timestamp, one or more operations of the write transaction by writing to the data of the partition at the two or more replicas of the partition
wherein one or more of the two or more replicas are configured to serve a first read transaction directed to reading, during the execution of the one or more operations of the write transaction, the data of the partition at a read timestamp that is (i) after the first timestamp and (ii) before the synthetic timestamp (fig. 6, items 665-690, execute the write transaction by, fig. 6, col. 13, lines 22-62, leader replica and plurality of replicas may advance its safe timestamp after all write requests have been received, or buffer the requests until they are received, when the read request timestamp is less than the sequence of write timestamp request. Note that Read request takes place when write requests are in buffer);
committing the one or more operations of the write transaction at the two or more replicas at or before the synthetic timestamp (items 680 and 690, col. 13, lines 42-46, and 60-62, transmitting the write to the replicas and receiving acknowledgement from a plurality of replicas that write has been completed).
32. The method of claim 31, wherein the maximum clock offset comprises a maximum allowed timestamp difference between any first clock and any second clock of the plurality of database nodes, wherein a timestamp difference between the first clock and the second clock is less than or equal to the maximum allowed timestamp difference (cols. 9-10, lines 39-3, time synch deamon calculate offset intervals for different locations of timestamps using clock synchronization for acceptable and functioning time masters corresponding to replicas/nodes, note that sets of timemaster offsets are validated against each other, wherein the method “employ an agreement algorithm to detect and reject offsets from malfunctioning time master” comprises maximum permittable differences, and col. 13, lines 15-31 “timestamp may be verified to ensure that it falls within the time lease reserved in block 610).
33. The method of claim 31, wherein the non-blocking duration is further determined as a function of the latency, the maximum clock offset, and a clock skew value, wherein the non-blocking duration is greater than or equal to a sum of the latency, the maximum clock offset, and the clock skew value (col. 11, lines 44-67, maximum lease duration value may be added to determine lease duration, col. 9, lines 39-45, multiple time masters used for multiple sites throughout the distributed system, and cols. 9-10, lines 39-3, time synch deamon calculate offset intervals for different locations of timestamps using clock synchronization for acceptable and functioning time masters, note that sets of timemaster offsets are validated against each other, wherein the method “employ an agreement algorithm to detect and reject offsets from malfunctioning time master”, and col. 13, lines 15-31 “timestamp may be verified to ensure that it falls within the time lease reserved in block 610).
35. The method of claim 31, wherein executing the one or more operations of the write transaction further comprises: writing one or more provisional values to the data of the two or more replicas of the partition (col. 10, lines 26-36, replicas may maintain a version of shard 1 at some point in time – this implies each replica has written provisional values); and appending, to at least one transaction log associated with the two or more replicas, the one or more operations of the write transaction (col. 13, lines 37-46, sequences of operations and acknowledgment creates history/log).
36. The method of claim 31, wherein the two or more replicas comprise a leader replica and one or more follower replicas wherein executing the one or more operations of the write transaction further comprises: sending, from the leader replica to the one or more follower replicas, the write transaction (fig. 5, col. 11, line 44 to col 12, line 3, replica becomes leader and comprises followers such as other replicas, and col. 13, lines 31-46, commit timestamp and leader replica transmitting to replica to write).
37. The method of claim 31, wherein the two or more replicas comprise a leader replica and one or more follower replicas , and further comprising: sending, from the leader replica to the one or more follower replicas, a closed timestamp update, wherein based on receiving the closed timestamp update, the one or more follower replicas are each configured to serve a first read transaction directed to reading the data of the partition at a timestamp that is (i) after the first timestamp and (ii) before the synthetic timestamp (col. 9, lines 39-45, multiple time masters used for multiple sites throughout the distributed system require timestamp update based on location and activity).
38. The method of claim 31, further comprising: determining, during the execution of the one or more operations of the write transaction and before the synthetic timestamp, a second present time indicated by the clock to be greater than or equal to a threshold timestamp, wherein the threshold timestamp is based on the synthetic timestamp and based on the determination the second present time indicated by the clock is greater than or equal to a threshold timestamp: (i) increasing the non-blocking duration (col. 4, line 60 to col. 5, line 9, increasing timestamps thus increasing the duration) and (ii) updating the synthetic timestamp based on the increased non-blocking duration, wherein the updated synthetic timestamp leads the first timestamp by the increased non-blocking duration (cols. 9-10, lines 39-3, time synch deamon calculate offset intervals for different locations of timestamps using clock synchronization for acceptable and functioning time masters, note that sets of timemaster offsets are validated against each other, wherein the method “employ an agreement algorithm to detect and reject offsets from malfunctioning time master”, and col. 13, lines 15-31 “timestamp may be verified to ensure that it falls within the time lease reserved in block 610 the verifying taking into account updated timestamps and offset intervals for multiple location replicas), wherein committing the one or more operations of the write transaction comprises committing the one or more operations of the write transaction at the two or more replicas at or before the updated synthetic timestamp (fig. 6, col. 13, lines 29-49, the new write transaction is broadcasted to the relevant replicas and executed, verified based on falling within the time lease reserved wherein time lease extension may be performed, to make sure the write happens in the sequence received, i.e., 0, 1, 2, 3).
39. The method of claim 31, further comprising: receiving a first read transaction directed to reading the data of the partition at a second timestamp, wherein the second timestamp is before the synthetic timestamp and after the first timestamp and, serving, during the execution of the one or more operations of the write transaction and from a replica of the two or more replicas, the first read transaction at the second timestamp based on determining the synthetic timestamp is external to an uncertainty interval, wherein the uncertainty interval is configured based on a sum (i) the second timestamp and (ii) the maximum clock offset (item 650, col. 14, lines 28-45, computer safe timestamp based on updated timestamps and fig. 6, items 610 and 660, col 14, lines 46-60, execute read transactions).
40. The method of claim 31, further comprising :receiving a first read transaction directed to reading the data of the partition at a second timestamp, wherein the second timestamp is before the synthetic timestamp and after the first timestamp (fig. 1, transaction 103, shards and multiple replicas, advance safe timestamp past the commit timestamp equated to second synthetic timestamp exceeds the third time by the duration, col. 13, lines 43-60 and adjusted location time); updating the second timestamp to a third timestamp based on determining the synthetic timestamp to be included in an uncertainty interval, wherein the third timestamp is after the synthetic timestamp, and wherein the uncertainty interval (item 650, col. 14, lines 28-45, computer safe timestamp) is configured based on a sum of (i) the second timestamp and (ii) the maximum clock offset; and serving, from a replica of the two or more replicas, the first read transaction at the third timestamp (item 650, col. 14, lines 28-45, computer safe timestamp and fig. 6, items 610 and 660, col 14, lines 46-60, execute read transactions, note that computed safe timestamp equals or exceeds the timestamp for the read operation).
41. The method of claim 31, further comprising: receiving a first read transaction directed to reading the data of the partition at a second timestamp, wherein the second timestamp is after the synthetic timestamp and serving, from a replica of the two or more replicas, the first read transaction at the second timestamp (item 650, col. 14, lines 28-45, computer safe timestamp and col. 10, lines 39, lead replica forwards requests to other replicas to execute the read/writes which comprises updating additional timestamps).
42. The method of claim 31, further comprising: sending, based on the committing and a threshold amount of time after the generation of the synthetic timestamp, an indication of success of the write transaction to a client device (figs. 1 and 6, col. 12, lines 49-63, Client sends and receives data/information via API), wherein the write transaction originated from the client device, wherein the threshold amount of time is based on the non-blocking duration (figs. 1 and 6, col. 12, lines 49-63, Client sends and therefore originates the transaction and receives data/information via API, note maximum lease duration value may be added to determine lease duration, col. 11, lines 44-67).
System Claims 43-45, 47-50 comprise substantially the same subject matter as rejected method claims 32-49 above, and are therefore rejected on the merits.
51. A computer-implemented method, comprising (figs. 1 and 3):
receiving a write transaction, wherein the write transaction is configured to write to data of two or more replicas of a partition stored by two or more database nodes of a plurality of database nodes (figs. 1, 3 and 6, item 615, 670 and 680, and col. 13, lines 31-42, transactions received such as write transaction, and the write transaction is broadcasted to replicas);
generating and associating, at a first database node of the plurality of database nodes, a synthetic timestamp with the write transaction, wherein the synthetic timestamp leads a first timestamp by a non-blocking duration, the first timestamp corresponding to a present time indicated by a clock corresponding to the first database node (fig. 6, items 620 and 670, col. 12 lines 64-67, and col. 13, lines 1-6 and 23-31, timestamp created/selected by a replication leader and time-interval based on lease which extends a base timestamp, and item 680, associate with the write node/transaction, and
cols. 9-10, lines 39-3, time synch deamon calculate offset intervals for different locations of timestamps using clock synchronization for acceptable and functioning time masters, note that sets of timemaster offsets are validated against each other, wherein the method “employ an agreement algorithm to detect and reject offsets from malfunctioning time master”, and col. 13, lines 15-31 “timestamp” may be verified to ensure that it falls within the time lease reserved in block 610);
executing, based on generating the synthetic timestamp, one or more operations of the write transaction by writing to the data of the partition at the two or more replicas of the partition, wherein one or more of the two or more replicas are configured to serve a first read transaction directed to reading, during the execution of the one or more operations of the write transaction, the data of the partition at a read timestamp that is (i) after the first timestamp and (ii) before the synthetic timestamp (fig. 6, items 665-690, execute the write transaction by, fig. 6, col. 13, lines 22-62, leader replica and plurality of replicas may advance its safe timestamp after all write requests have been received, or buffer the requests until they are received, when the read request timestamp is less than the sequence of write timestamp request. Note that Read request takes place when write requests are in buffer);
determining, during the execution of the one or more operations of the write transaction and before the synthetic timestamp, a second present time indicated by the clock to be greater than or equal to a threshold timestamp, wherein the threshold timestamp is based on the synthetic timestamp (fig. 1, col. 4, line 60 to col. 5, line 9, increasing timestamps thus increasing the duration, and (figs. 1, 3 and 6, item 615, 620, 670 and 680, and col. 13, lines 31-42, transactions received such as write transaction, and the write transaction when broadcasted to replicas, each write comprises a timestamp and a commit timestamp greater than the last commit timestamp from block 620 when committing/writing at the replica);
based on the determination the second present time indicated by the clock is greater than or equal to the threshold timestamp:(i) increasing the non-blocking duration (col. 4, line 60 to col. 5, line 9, increasing timestamps thus increasing the duration) and (ii) updating the synthetic timestamp based on the increased non-blocking duration, wherein the updated synthetic timestamp leads the first timestamp by the increased non-blocking duration (cols. 9-10, lines 39-3, time synch deamon calculate offset intervals for different locations of timestamps using clock synchronization for acceptable and functioning time masters, note that sets of timemaster offsets are validated against each other, wherein the method “employ an agreement algorithm to detect and reject offsets from malfunctioning time master”, and col. 13, lines 15-31 “timestamp may be verified to ensure that it falls within the time lease reserved in block 610 the verifying taking into account updated timestamps and offset intervals for multiple location replicas); and
committing the one or more operations of the write transaction at the two or more replicas at or before the updated synthetic timestamp (items 680 and 690, col. 13, lines 42-46, and 60-62, transmitting the write to the replicas and receiving acknowledgement from a plurality of replicas that write has been completed).
52. A computer-implemented method, comprising:
receiving a write transaction, wherein the write transaction is configured to write to data of two or more replicas of a partition stored by two or more database nodes of a plurality of database nodes (figs. 1, 3 and 6, item 615, 670 and 680, and col. 13, lines 31-42, transactions received such as write transaction, and the write transaction is broadcasted to replicas);
generating and associating, at a first database node of the plurality of database nodes, a synthetic timestamp with the write transaction, wherein the synthetic timestamp leads a first timestamp by a non-blocking duration, the first timestamp corresponding to a present time indicated by a clock corresponding to the first database node (fig. 6, items 620 and 670, col. 12 lines 64-67, and col. 13, lines 1-6 and 23-31, timestamp created/selected by a replication leader and time-interval based on lease which extends a base timestamp, and item 680, associate with the write node/transaction, and cols. 9-10, lines 39-3, time synch deamon calculate offset intervals for different locations of timestamps using clock synchronization for acceptable and functioning time masters, note that sets of timemaster offsets are validated against each other, wherein the method “employ an agreement algorithm to detect and reject offsets from malfunctioning time master”, and col. 13, lines 15-31 “timestamp” may be verified to ensure that it falls within the time lease reserved in block 610);
executing, based on generating the synthetic timestamp, one or more operations of the write transaction by writing to the data of the partition at the two or more replicas of the partition, wherein one or more of the two or more replicas are configured to serve a first read transaction directed to reading, during the execution of the one or more operations of the write transaction, the data of the partition at a read timestamp that is (i) after the first timestamp and (ii) before the synthetic timestamp (fig. 6, items 665-690, execute the write transaction by, fig. 6, col. 13, lines 22-62, leader replica and plurality of replicas may advance its safe timestamp after all write requests have been received, or buffer the requests until they are received, when the read request timestamp is less than the sequence of write timestamp request. Note that Read request takes place when write requests are in buffer);
receiving a first read transaction directed to reading the data of the partition at a second timestamp, wherein the second timestamp is before the synthetic timestamp and after the first timestamp and serving, during the execution of the one or more operations of the write transaction and from a replica of the two or more replicas, the first read transaction at the second timestamp based on determining the synthetic timestamp is external to an uncertainty interval, wherein the uncertainty interval is configured based on a sum of (i) the second timestamp and (ii) a maximum clock offset between any pair of clocks of the plurality of database nodes (item 650, col. 14, lines 28-45, computer safe timestamp based on updated timestamps and fig. 6, items 610 and 660, col 14, lines 46-60, execute read transactions); and,
committing the one or more operations of the write transaction at the two or more replicas at or before the synthetic timestamp (items 680 and 690, col. 13, lines 42-46, and 60-62, transmitting the write to the replicas and receiving acknowledgement from a plurality of replicas that write has been completed).
Response to Arguments
Applicant's arguments filed 6/1/26 have been fully considered but they are not persuasive. See remarks below.
Applicant alleges the new amended features are not present in Hsieh such as “leads a first timestamp…”.
Examiner disagrees.
The relevant portion of the updated office action reads,
“wherein the synthetic timestamp leads a first timestamp by a non-blocking duration, the first timestamp corresponding to a present time indicated by a clock corresponding to the first database node and wherein the non-blocking duration is determined as a function of (i) a latency between a pair of database nodes of the plurality of database nodes and (ii) a maximum clock offset between any pair of clocks of the plurality of database nodes (fig. 6, items 620 and 670, col. 12 lines 64-67, and col. 13, lines 1-6 and 23-31, timestamp created/selected by a replication leader and time-interval based on lease which extends a base timestamp, and item 680, associate with the write node/transaction, and
cols. 9-10, lines 39-3, time synch deamon calculate offset intervals for different locations of timestamps using clock synchronization for acceptable and functioning time masters, note that sets of timemaster offsets are validated against each other, wherein the method “employ an agreement algorithm to detect and reject offsets from malfunctioning time master”, and col. 13, lines 15-31 “timestamp” may be verified to ensure that it falls within the time lease reserved in block 610)”.
The selected timestamps in combination with lease timestamps which extend a base timestamp ensure that the writes can be performed in sequence during the time difference of the respective timestamps. For details please refer to the rejection with regard to timestamps and performing writes and reads using timestamp verification and extension.
Applicant alleges the amended feature of “serve…before synthetic timestamp” is not suggested by Hsieh.
Examiner disagrees.
The relevant portion of the office action reads,
“executing, based on generating the synthetic timestamp, one or more operations of the write transaction by writing to the data of the partition at the two or more replicas of the partition wherein one or more of the two or more replicas are configured to serve a first read transaction directed to reading, during the execution of the one or more operations of the write transaction, the data of the partition at a read timestamp that is (i) after the first timestamp and (ii) before the synthetic timestamp (fig. 6, items 665-690, execute the write transaction by, fig. 6, col. 13, lines 22-62, leader replica and plurality of replicas may advance its safe timestamp after all write requests have been received, or buffer the requests until they are received, when the read request timestamp is less than the sequence of write timestamp request. Note that Read request takes place when write requests are in buffer);
Safe timestamp is executed for all the write requests to take place. For example, the system may perform any Read requests when Write requests are in buffer.
In addition with regard to claim 39, Hsieh clearly teaches enabling the Read requests by enabling the respective timestamps including safe timestamp. As such, this allegation is believed moot.
Last, with regard to new independent claims 51 and 52, Examiner has addressed the claims in the updated office action including all the limitations. Applicant is advised to focus on one scope of the claimed subject matter in all the independent claims to expedite examination and not invoke a Restriction in view of possible distinct teachings/inventions.
Previous relevant responses:
Applicant alleges the “calculating duration” as claimed is not taught by the prior art.
Examiner is not persuaded.
The relevant section of the rejection reads,
“calculating a duration by adding at least (i) a latency between a pair of database nodes of the plurality of database nodes (col. 8, lines 60-67, calculate synchronization offset intervals that is relative to each time master e.g., an interval between local time and a time master’s representation) and (ii) a maximum clock offset between a pair of clocks of the plurality of database nodes (cols. 9-10, lines 39-3, time synch deamon calculate offset intervals for different locations of timestamps using clock synchronization for acceptable and functioning time masters, note that sets of timemaster offsets are validated against each other, wherein the method “employ an agreement algorithm to detect and reject offsets from malfunctioning time master”, and col. 13, lines 15-31 “timestamp may be verified to ensure that it falls within the time lease reserved in block 610) wherein the duration is greater than or equal to a sum of the latency and maximum clock offset (items 665, 670 and 680, the commit timestamp is based on the interval greater than the last commit timestamp 620 which is further verified, col. 13, lines 15-31)”.
The limitation refers to a “write transaction” in the claim and not write and read management as alleged in the remarks. For example, the independent claims do not mention a “read transaction” which is the essence of the inventive subject matter in conjunction with write transaction handling in a network of plurality of nodes, described in the specification and allowed in the parent application. A mere write transaction is offset by Hsieh system by calculating an offset between a pair of clocks between nodes (see rejection above). The calculation takes into consideration timestamps of different locations of nodes and uses further validation which in combination performs the claimed limitation. As such, this allegation is believed moot.
Applicant alleges the “generating and associating… a synthetic timestamp” as claimed is not taught by the prior art.
Examiner is not persuaded.
The relevant section of the rejection reads,
“generating and associating, at a database node of the plurality of database nodes, a synthetic timestamp with the write transaction, wherein the synthetic timestamp is generated by adding (i) a first timestamp corresponding to a present time indicated by a clock corresponding to the database node and (ii) the duration (fig. 6, items 620 and 670, col. 12 lines 64-67, and col. 13, lines 1-6 and 23-31, timestamp created/selected by a replication leader and time-interval based on lease which extends a base timestamp, and item 680, associate with the write node/transaction)”.
Hsieh generates a plurality of timestamps and intervals based on lease. The system publishes next-write timestamps from an extendable time lease and tracking a “safe timestamp” (see abstract). The extendable timestamps enable the Hsieh Read queries be executed within the range of adjusted timestamps and without “blocking future write transactions” (see abstract). As a result, the replication leader in combination with lease feature and extendable timestamps, for the safe timestamp to catch up to the read timestamp (fig. 6, item 650) and execute the read transaction (fig. 6, item 660). For additional details please refer to figure 6, items 610-690 and the rejection above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure in the field of time-series databases:
USPN. 11397752: KWIC 26, replicas with partitions. USPN. 20110216660: par. 19, global timestamps, nodes replication.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARCIN R FILIPCZYK whose telephone number is (571)272-4019. The examiner can normally be reached M-F 7-4 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached on 571-272-8352. 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.
June 25, 2026
/MARCIN R FILIPCZYK/Primary Examiner, Art Unit 2153
Prosecution Insights