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 .
Response to Amendment
This communication is in response to the amendment filed on 12 November 2025.
No claim are canceled.
No claims are amended.
Claims 1-20 have been examined.
Response to Arguments
In response to Applicant’s remarks filed on 12 November 2025:
a. Rejections of the pending claims under 35 U.S.C. 101 are withdrawn in view of Applicant’s remarks.
b. Applicant's arguments with respect to the 35 U.S.C. 103 rejections of the pending claims have been fully considered but are not deemed persuasive.
On pages 10-13 of Applicant’s remarks, Applicant argues that the cited prior art fails to teach or suggest the limitations of claim 1. In particular, Applicant argues that VanBenschoten fails to teach or suggest evaluating transaction status information as claimed, asserting a distinction between VanBenschoten’s uncertainty interval and the claimed “transaction status information maintained at the storage node and the rowblock” (remarks, page 11, first full paragraph, emphasis is Applicant’s).
The Office respectfully disagrees with the above remarks. VanBenschoten teaches that rows of a database table are blocked into ranges 160 of keys (VanBenschoten para. 0002, 0026, and Fig. 2A). VanBenschoten’s ranges 160 correspond to rowblocks as disclosed in Applicant’s invention (see, for example, para. 0027-0028 of Applicant’s published specification). VanBenschoten utilizes an “uncertainty interval” associated with a particular transaction to evaluate whether or not another transaction conflicts with the particular transaction (VanBenschoten para. 0129-0130). VanBenschoten’s uncertainty interval, as its name suggests, provides information about when the associated transaction will remain uncertain (Ibid.). Furthermore, VanBenschoten’s uncertainty interval is maintained at the level of the ranges 160, each of which exists within a particular node 120 (VanBenschoten para. 0127-0130 and Fig. 2A). Hence, VanBenschoten’s uncertainty interval corresponds to “transaction status information maintained at the storage node and the rowblock,” and VanBenschoten teaches the “evaluate” limiation of claim 1 as claimed.
Claims 5 and 13 recite limitations similar to those of claim 1 and are unpatentable over the prior art for the same reasons that claim 1 is unpatentable, as set forth above.
Claims 2-4, 6-12, and 14-20 are unpatentable over the prior art for the same reasons that claims 1, 5, and 13 are unpatentable, as set forth above.
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 of this title, 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 1, 2, 4-8, 10-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over VanBenschoten et al. (U.S. Patent Application Publication No. 20230021150 A1, hereinafter referred to as VanBenschoten) in view of Diaconu et al. (U.S. Patent Application Publication No. 20240394244 A1, hereinafter referred to as Diaconu).
As to claim 1, VanBenschoten teaches a system, comprising:
a first plurality of nodes, respectively comprising at least one processor and a memory (VanBenschoten Fig. 4 and para. 0145: computing devices comprise processor 410 coupled to memory 420), that implement a database service that provides access to databases on behalf of clients of the database service (VanBenschoten para. 0025 and Fig. 1: cluster 102 of computing device/nodes 120 that provide a database to clients 106; and VanBenschoten para. 0067: the cluster stores multiple databases);
wherein the database service comprises a first data access node and a second data access node (VanBenschoten Fig. 1: nodes 120a and 120b), wherein the first data access node sends one or more write requests as part of a first transaction (VanBenschoten para. 0064: transactions issue requests, including write requests; and VanBenschoten para. 0069: write requests) to a storage node (VanBenschoten para. 0066 and Fig. 1: conflicting transactions write to the same node), and wherein the second data access node sends one or more further write requests as part of a second transaction (VanBenschoten para. 0064: transactions issue requests, including write requests; and VanBenschoten para. 0069: write requests) to the storage node (VanBenschoten para. 0066 and Fig. 1: conflicting transactions write to the same node);
wherein the storage node is configured to:
receive a request to prepare the first transaction (VanBenschoten para. 0064: transactions issue requests, including write requests; and VanBenschoten para. 0069: write requests);
identify a first version of a record associated with the first transaction and a first transaction time associated with the first version of the record (VanBenschoten para. para. 0105: timestamps are used to differentiate different versions of the data; and VanBenschoten para. 0051: multi-version concurrency control);
identify a rowblock that has a record identifier range that includes the record and a time value range that includes a first transaction time (VanBenschoten para. 0002, 0026, and Fig. 2A: rows of the table are blocked into ranges 160 of keys; and VanBenschoten para. 0129-0130: uncertainty interval is a time interval; Note: VanBenschoten’s uncertainty interval corresponds to the claimed “time value range”);
evaluate transaction status information maintained at the storage node and the rowblock to determine that the first transaction conflicts with the second transaction with an acknowledged prepare request for a second version of the record with a second transaction time that is also stored in the rowblock (VanBenschoten para. 0129-0130: uncertainty interval is a time interval; “a write transaction within the uncertainty interval” results in a conflict).
VanBenschoten does not appear to explicitly disclose a second plurality of nodes, respectively comprising at least one further processor and a further memory, that implement a distributed storage service that stores tables of the databases on behalf of the database service; wherein the database service comprises a first data access node and a second data access node, wherein the first data access node sends one or more write requests as part of a first transaction to a storage node of the distributed storage service via a first storage service engine, and wherein the second data access node sends one or more further write requests as part of a second transaction to the storage node via a second storage service engine; and send a response indicating that the request to prepare the first transaction conflicts with the second transaction.
However, Diaconu teaches a system, comprising:
a first plurality of nodes, respectively comprising at least one processor and a memory (Diaconu Fig. 16: processors 1610 coupled to memory 1630), that implement a database service that provides access to databases on behalf of clients of the database service (Diaconu Fig. 1: data warehouse system 102 providing service to client 114; and Diaconu para. 0323 and Fig. 16: multiple devices 1670 connect to the system as clients);
a second plurality of nodes, respectively comprising at least one further processor and a further memory (Diaconu Fig. 16: processors 1610 coupled to memory 1630), that implement a distributed storage service that stores tables of the databases on behalf of the database service (Diaconu Fig. 1: storage platform 104 comprising data storage devices 120; and Diaconu abstract: the distributed data store stores database tables);
wherein the database service comprises a first data access node and a second data access node (Diaconu para. 0036 and Fig. 1: data warehouse system 102 is distributed across multiple computing systems/platforms), wherein the first data access node sends one or more write requests as part of a first transaction to a storage node of the distributed storage service via a first storage service engine, and wherein the second data access node sends one or more further write requests as part of a second transaction to the storage node via a second storage service engine (Diaconu Fig. 1: storage platform 104 comprising data storage devices 120-1 and 120-2; and Diaconu para. 0063 and Fig. 1: write transactions);
receive a request to prepare the first transaction from the first data access node (Diaconu para. 0063 and Fig. 1: write transactions);
send a response indicating that the request to prepare the first transaction conflicts with the second transaction (Diaconu para. 0189-0190: response to conflict).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified VanBenschoten to include the teachings of Diaconu because it enables logical ordering across database statements with the use of table locks and while avoiding execution using outdated table metadata (Diaconu para. 0025).
As to claim 2, VanBenschoten as modified by Diaconu teaches wherein the storage node is further configured to:
receive a request to commit the second transaction (VanBenschoten para. 0052: request to commit); and
update the second version of the record with a visibility time for multiversion concurrency control (MVCC) and the transaction status information to indicate that the second transaction is committed (VanBenschoten para. 0053: updating multiversion concurrency control (MVCC) and transaction record to indicate committed transaction).
As to claim 4, VanBenschoten as modified by Diaconu teaches wherein the storage node is further configured to: receive a request to abort the first transaction; and update the transaction status information to rollback the first transaction, making the first version of the record ready for reclamation in the rowblock (VanBenschoten para. 0050 and 0052: transaction aborted; and Diaconu para. 0072 and 0089: transaction rollback).
As to claim 5, VanBenschoten teaches a method, comprising:
receiving, at a storage node of a distributed storage service (VanBenschoten para. 0025 and Fig. 1: cluster 102 of computing device/nodes 120 that provide a database to clients 106), a request to prepare a first transaction performed on behalf of a first database access application (VanBenschoten para. 0064: transactions issue requests, including write requests; and VanBenschoten para. 0069: write requests);
identifying, by the storage node, a first version of a record associated with the first transaction and a first transaction time associated with the first version of the record (VanBenschoten para. para. 0105: timestamps are used to differentiate different versions of the data; and VanBenschoten para. 0051: multi-version concurrency control);
identifying, by the storage node, a rowblock that has a record identifier range that includes the record and a time value range that includes a first transaction time (VanBenschoten para. 0002, 0026, and Fig. 2A: rows of the table are blocked into ranges 160 of keys; and VanBenschoten para. 0129-0130: uncertainty interval is a time interval; Note: VanBenschoten’s uncertainty interval corresponds to the claimed “time value range”);
evaluating, by the storage node, transaction status information maintained at the storage node and the rowblock to determine that the first transaction conflicts with a second transaction with an acknowledged prepare request for a second version of the record with a second transaction time that is also stored in the rowblock (VanBenschoten para. 0129-0130: uncertainty interval is a time interval; “a write transaction within the uncertainty interval” results in a conflict).
VanBenschoten does not appear to explicitly disclose sending, by the storage node, a response indicating that the request to prepare the first transaction conflicts with the second transaction.
However, Diaconu teaches:
receiving, at a storage node of a distributed storage service (Diaconu Fig. 1: storage platform 104 comprising data storage devices 120; and Diaconu abstract: the distributed data store stores database tables), a request to prepare a first transaction performed on behalf of a first database access application (Diaconu para. 0063 and Fig. 1: write transactions);
sending, by the storage node, a response indicating that the request to prepare the first transaction conflicts with the second transaction (Diaconu para. 0189-0190: response to conflict).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified VanBenschoten to include the teachings of Diaconu because it enables logical ordering across database statements with the use of table locks and while avoiding execution using outdated table metadata (Diaconu para. 0025).
As to claim 6, see the rejection of claim 2 above.
As to claim 7, VanBenschoten as modified by Diaconu teaches receiving, at the storage node, the request to prepare the second transaction (VanBenschoten para. 0069: write requests); and responding to a second database application via a storage service engine that the second transaction is prepared after determining that the second transaction can be prepared according to an evaluation of the transaction status information and the rowblock (VanBenschoten para. 0130: transaction may execute after a duration of time).
As to claim 8, VanBenschoten as modified by Diaconu teaches further comprising:
receiving, at the storage node, the request to abort the second transaction (VanBenschoten para. 0050 and 0052: transaction aborted; and Diaconu para. 0072 and 0089: transaction rollback);
updating the transaction status information to indicate that the second transaction is aborted (VanBenschoten para. 0050 and 0052: transaction aborted; and Diaconu para. 0072 and 0089: transaction rollback); and
responding to a further request to prepare the first transaction from the first database application that the first transaction is prepared after determining that the second transaction can be prepared according to an evaluation of the transaction status information and the rowblock (VanBenschoten para. 0130: transaction may execute after a duration of time).
As to claim 10, see the rejection of claim 4 above.
As to claim 11, VanBenschoten as modified by Diaconu teaches wherein the storage node is a member of a protection group that stores respective segments of a table at different storage nodes (VanBenschoten para. 0002 and Fig. 1: ranges of a table are replicated among multiple devices of the cluster).
As to claim 12, this claim merely describes a technological environment in which to apply the invention, without any limitations upon the claimed. Hence, this claim amounts to no more than intended use of the claimed invention and it has no patentable weight. However, assuming arguendo that the claim has patentable weight, prior art is cited.
VanBenschoten as modified by Diaconu teaches wherein the request to prepare the transaction is received via storage service engine implemented with the database access application at a host implemented in a database service of a provider network and wherein the distributed storage service is also implemented as part of the provider network (VanBenschoten para. 0039: storage engine; and Diaconu para. 0032 and Fig. 1: compute service manager 108).
As to claim 13, VanBenschoten teaches one or more non-transitory, computer-readable storage media, storing program instructions that when executed on or across one or more computing devices cause the one or more computing devices to implement (VanBenschoten para. 0148 and Fig. 4: computer readable medium storing instructions for one or more processing devices):
receiving, at a storage node of a distributed storage service (VanBenschoten para. 0025 and Fig. 1: cluster 102 of computing device/nodes 120 that provide a database to clients 106), a request to prepare a first transaction performed on behalf of a first database access application (VanBenschoten para. 0064: transactions issue requests, including write requests; and VanBenschoten para. 0069: write requests);
identifying, by the storage node, a first version of a record associated with the first transaction and a first transaction time associated with the first version of the record (VanBenschoten para. para. 0105: timestamps are used to differentiate different versions of the data; and VanBenschoten para. 0051: multi-version concurrency control);
identifying, by the storage node, a rowblock that has a record identifier range that includes the record and a time value range that includes a first transaction time (VanBenschoten para. 0002, 0026, and Fig. 2A: rows of the table are blocked into ranges 160 of keys; and VanBenschoten para. 0129-0130: uncertainty interval is a time interval; Note: VanBenschoten’s uncertainty interval corresponds to the claimed “time value range”);
evaluating, by the storage node, transaction status information maintained at the storage node and the rowblock to determine that the first transaction conflicts with a second transaction with an acknowledged prepare request for a second version of the record with a second transaction time that is also stored in the rowblock (VanBenschoten para. 0129-0130: uncertainty interval is a time interval; “a write transaction within the uncertainty interval” results in a conflict).
VanBenschoten does not appear to explicitly disclose sending, by the storage node, a response indicating that the request to prepare the first transaction conflicts with the second transaction.
However, Diaconu teaches:
receiving, at a storage node of a distributed storage service (Diaconu Fig. 1: storage platform 104 comprising data storage devices 120; and Diaconu abstract: the distributed data store stores database tables), a request to prepare a first transaction performed on behalf of a first database access application (Diaconu para. 0063 and Fig. 1: write transactions);
sending, by the storage node, a response indicating that the request to prepare the first transaction conflicts with the second transaction (Diaconu para. 0189-0190: response to conflict).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified VanBenschoten to include the teachings of Diaconu because it enables logical ordering across database statements with the use of table locks and while avoiding execution using outdated table metadata (Diaconu para. 0025).
As to claim 14, see the rejection of claim 2 above.
As to claim 15, see the rejection of claim 7 above.
As to claim 16, see the rejection of claim 8 above.
As to claim 18, see the rejection of claim 4 above.
As to claim 19, see the rejection of claim 11 above.
As to claim 20, see the rejection of claim 12 above.
Claims 3, 9, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over VanBenschoten and Diaconu as applied to claims 1, 5, and 13 above, and further in view of Friedlander et al. (U.S. Patent Application Publication No. 20150081694 A1, hereinafter referred to as Friedlander).
As to claim 3, VanBenschoten as modified by Diaconu teaches update the rowblock to store the first version of the record and the second version of the record.
VanBenschoten as modified by Diaconu does not appear to explicitly disclose wherein the storage engine performs a copy-on-write technique to update.
However, Friedlander teaches wherein the storage engine performs a copy-on-write technique to update (Friedlander para. 0003: copy-on-write technique for updating data structure).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified VanBenschoten as modified by Diaconu to include the teachings of Friedlander because it provides a guarantee of atomicity, preventing updates to a data structure from occurring only partially (Friedlander para. 0016).
As to claim 9, see the rejection of claim 3 above.
As to claim 17, see the rejection of claim 3 above.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to UMAR MIAN whose telephone number is (571)270-3970. The examiner can normally be reached Monday to Friday, 10 am to 6:30 pm.
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, Tony Mahmoudi can be reached on (571) 272-4078. 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.
/Umar Mian/
Examiner, Art Unit 2163