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 .
Extrinsic Evidence
3.4. Transactions: https://www.postgresql.org/docs/current/tutorial-transactions.html
In PostgreSQL, a transaction is set up by surrounding the SQL commands of the transaction with BEGIN and COMMIT commands. So our banking transaction would actually look like:
BEGIN;
UPDATE accounts SET balance = balance - 100.00
WHERE name = 'Alice';
-- etc etc
COMMIT;
If, partway through the transaction, we decide we do not want to commit (perhaps we just noticed that Alice's balance went negative), we can issue the command ROLLBACK instead of COMMIT, and all our updates so far will be canceled.
PostgreSQL actually treats every SQL statement as being executed within a transaction. If you do not issue a BEGIN command, then each individual statement has an implicit BEGIN and (if successful) COMMIT wrapped around it. A group of statements surrounded by BEGIN and COMMIT is sometimes called a transaction block.
Note
Some client libraries issue BEGIN and COMMIT commands automatically, so that you might get the effect of transaction blocks without asking. Check the documentation for the interface you are using.
It's possible to control the statements in a transaction in a more granular fashion through the use of savepoints. Savepoints allow you to selectively discard parts of the transaction, while committing the rest. After defining a savepoint with SAVEPOINT, you can if needed roll back to the savepoint with ROLLBACK TO. All the transaction's database changes between defining the savepoint and rolling back to it are discarded, but changes earlier than the savepoint are kept.
After rolling back to a savepoint, it continues to be defined, so you can roll back to it several times. Conversely, if you are sure you won't need to roll back to a particular savepoint again, it can be released, so the system can free some resources. Keep in mind that either releasing or rolling back to a savepoint will automatically release all savepoints that were defined after it.
All this is happening within the transaction block, so none of it is visible to other database sessions. When and if you commit the transaction block, the committed actions become visible as a unit to other sessions, while the rolled-back actions never become visible at all.
Remembering the bank database, suppose we debit $100.00 from Alice's account, and credit Bob's account, only to find later that we should have credited Wally's account. We could do it using savepoints like this:
BEGIN;
UPDATE accounts SET balance = balance - 100.00
WHERE name = 'Alice';
SAVEPOINT my_savepoint;
UPDATE accounts SET balance = balance + 100.00
WHERE name = 'Bob';
-- oops ... forget that and use Wally's account
ROLLBACK TO my_savepoint;
UPDATE accounts SET balance = balance + 100.00
WHERE name = 'Wally';
COMMIT;
This example is, of course, oversimplified, but there's a lot of control possible in a transaction block through the use of savepoints. Moreover, ROLLBACK TO is the only way to regain control of a transaction block that was put in aborted state by the system due to an error, short of rolling it back completely and starting again.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 5-11, and 13--20 are rejected under 35 U.S.C. 103 as being unpatentable over Park (U.S. Pub 2016/0371357, in view of Singh (U.S. Patent 11874822 B1)
Claim 1
Park discloses a computer-implemented method comprising:
receiving, from a client (a client 110) at a leader server ( source system 120), a command to perform a change operation (insert, change, delete operations) on a row of a table of a database ([0048], line 1-5, “… The source system, 120 can receive data manipulation operations (e.g., operations to add, modify, and/or delete data, such as in the form of insert, update, and/or delete DML statements) from the client 110…” <examiner note: Client sends insert, change, delete operation to source system 120. Insert, change, delete statements perform database operations on rows/records of tables of database>), wherein:
the row of the table is replicated on a replication group of servers such that each server within the replication group of servers stores a respective copy of the row of the table ([0048], line 9-12, “… The source system 120 can also create write log entries incorporating the DML statements and send them (as depicted at 140) to a replica system 130 for execution….” [0049], “… The replica system 130 can receive the write logs and execute the entries contained within, including DML statements… The replica system 130 can replicate database information stored at the source system 120 (e.g., one or more database tables) via DML statements (e.g., so that database data changes at the source system 120 are replicated to the replica system 130)…”),
the command is associated with a particular transaction ([0033], line 1-4, “… a write log entry comprises a transaction identifier (ID), a DML statement, parameter values, and nondeterministic values…” <examiner note: For instance, the insert command is associated with transaction 1>),
PNG
media_image1.png
145
433
media_image1.png
Greyscale
the replication group of servers includes the leader server and a plurality of follower servers (fig. 2, source 210 [Wingdings font/0xF3] leader, replication nodes 220, 230 [Wingdings font/0xF3] followers), and
the leader server is configured to perform data manipulation language (DML) operations on the row of the table and replicate the DML operations to the plurality of follower servers ([0048], line 5-12, “… Upon receiving the data manipulation operations…, the source system 120 can execute DML statements to perform the data manipulation operations… The source system 120 can also create write log entries incorporating the DML statements and send them (as depicted at 140) to a replica system 130 for execution. [0049], “… The replica system 130 can receive the write logs and execute the entries contained within, including DML statements… The replica system 130 can replicate database information stored at the source system 120 (e.g., one or more database tables) via DML statements…”);
performing, by the leader server, the change operation on the copy of the row of the table stored at the leader server ([0048], line 5-12, “… Upon receiving the data manipulation operations…, the source system 120 can execute DML statements to perform the data manipulation operations…” [0052], line 7-8, “… execute the DML statement on one of the database tables 216 (e.g., to add, modify, and/or delete data in the database table…);
in response to the leader server performing the change operation, creating, by the leader server, a replication log record for the change operation in a replication pipeline to be replicated to the plurality of follower servers asynchronously ([0052], line 7-12, “… execute the DML statement on one of the database tables 216… then create a write log entry (which includes the DML statement) and insert the write log entry into the write log queue 214…” [0055], line 3-7, “… The replication handler 218 can take write logs from the write log queue 214 and send them to one or more replica nodes… in order for the replica nodes to perform replication by executing the DML statements contained within the write log entries…” <examiner note: the followers execute DML operations in the write log asynchronously because the leader performs the DML operation before the followers apply the same DML operations>);
in response to the leader server creating the replication log record for the change operation in the replication pipeline ([0027], line 10-11, “… write logs are created reflecting the DML statement and transaction commit operations…” [0048], “… The source system 120 can also create write log entries…), returning a result of the change operation from the leader server to the client (fig. 3, transaction coordinator return TXN success 350 to client)
PNG
media_image2.png
641
559
media_image2.png
Greyscale
wherein the method is performed by one or more computing devices (fig. 2b, nodes 120a-c).
However, Park does not explicitly disclose
receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction;
creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol
Singh discloses
receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction (col 10, line 43-45, “… at 310, the client 104 may send an initialize (init) transaction request… to begin a transaction…” col 10, line 48-49, “… at 312… the init transaction request to a transaction coordinator…” col 20, line 50-67 <examiner note: as provided in extrinsic evidence, a transaction is set up by surrounding the SQL commands of the transaction with BEGIN, ROLLBACK, COMMIT commands. These command rollback and commit are transaction directive command for the transaction>); and
creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol (col 10, line 53-55, “… at 314, the transaction coordinator 110 allocates a transaction identifier for the transaction… and persist… in the transaction log 116, e.g., along with other relevant transaction metadata…” <examiner note: transaction log 116 in fig. 1 shows status of the transaction as committed aborted committing, open…> col 11, line 5-25, “… The transaction coordinator 110 also sends a “committing” command as shown at 332 to each identified designated writer for the involved shards in the transaction… Each designated writer 120 thus determines whether it is possible to commit the events of the transaction from its perspective… If everything is able to be written, each designated writer 120 returns a positive indication that all is good… When all responses back are positive… the transaction coordinator 110 can send a “commit” command 338 and 340 to the involved designated writers 120, which commit the events at 342, and return success messages at 344 and 346. Thus, the transaction coordinator 110 can update the transaction status in the transaction log 116 (e.g., to “committed”, possibly along with other metadata updates such as updating a last update time) at 348 and return an indication of the status (e.g., success) to the client 104…”)
Park discloses DML operations are performed transactions and log shipping are implemented in distributed database. However, Park does not explicitly disclose receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction and creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol. Singh discloses a transaction coordinator and transaction buffer to support running ACID transaction across multiple streams spanning multiple shards. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporating the transactional eventing service with built in support for event conditions that allow users to place conditions that must be met in order for events to be accepted into the store, and optimistic concurrency control to guarantee write consistency by preventing users from accidentally overwriting changes that were made by others.
Claim 15 is similar to claim 1. The claim is rejected based on the same reason
Claim 2
Claim 1 is included, Singh discloses wherein:
the transaction directive command is a commit command to perform a commit operation for the particular transaction (col 10, line 43-45, “… at 310, the client 104 may send an initialize (init) transaction request… to begin a transaction…” col 10, line 48-49, “… at 312… the init transaction request to a transaction coordinator…” <examiner note: as provided in extrinsic evidence, a transaction is set up by surrounding the SQL commands of the transaction with BEGIN, ROLLBACK, COMMIT commands. These command rollback and commit are transaction directive command for the transaction>),
the method further comprises:
in response to the leader server receiving acknowledgement that the replication log record for the commit operation has been appended to a replication log of a consensus number of the plurality of follower servers, performing the commit operation on the particular transaction on the copy of the row of the table at the leader server (col 11, line 5-25, “… The transaction coordinator 110 also sends a “committing” command as shown at 332 to each identified designated writer for the involved shards in the transaction… Each designated writer 120 thus determines whether it is possible to commit the events of the transaction from its perspective… If everything is able to be written, each designated writer 120 returns a positive indication that all is good… When all responses back are positive… the transaction coordinator 110 can send a “commit” command 338 and 340 to the involved designated writers 120, which commit the events at 342, and return success messages at 344 and 346. Thus, the transaction coordinator 110 can update the transaction status in the transaction log 116 (e.g., to “committed”, possibly along with other metadata updates such as updating a last update time) at 348 and return an indication of the status (e.g., success) to the client 104…”); and
returning a result of the commit operation to the client (col 11, line 5-25, “…, the transaction coordinator 110 can update the transaction status in the transaction log 116 (e.g., to “committed”, possibly along with other metadata updates such as updating a last update time) at 348 and return an indication of the status (e.g., success) to the client 104…”)
Claim 16 is similar to claim 2. The claim is rejected based on the same reason
Claim 3
Claim 2 is included, Singh discloses wherein a given acknowledgement received from a given follower server includes multiple transaction commits (fig. 1, shard A, has transactions ID 4, 6 commits)
PNG
media_image3.png
274
359
media_image3.png
Greyscale
Claim 5
Claim 2 is included, Singh discloses wherein performing the commit operation comprises writing log records for the particular transaction to disk (col 9, line 4-6, “… the transaction coordinator 110 persist this transaction metadata 123 in a persistent storage (e.g., a transaction log 116)…” col 11, line 1-5, “… In a commit stage 306, the transaction coordinator 110 may attempt to commit the events of the transaction. The transaction coordinator 110 may update a transaction status of the metadata entry for the transaction in the transaction log 116 to be “committing” at 330…” fig. 15, Transaction eventing service in system memory 1520 (i.e., computer-accessible medium [Wingdings font/0xF3] , col 29-col 30)
Claim 6
Claim 1 is included, Singh further discloses wherein: the transaction directive command is a commit command to perform a commit operation for the particular transaction, the method further comprises: preparing the particular transaction for commit at the leader server; marking the particular transaction as in-doubt; in response to the leader server failing and becoming a new follower server, determining whether there is consensus that the replication log record for the commit operation has been appended to a replication log of a consensus number of the plurality of follower servers; in response to determining there is consensus, performing the commit operation on the particular transaction on the copy of the row of the table at the new follower server; and in response to determining there is no consensus, rolling back the particular transaction at the new follower server (col 13, line 24-44, “… After all events in a transaction are published at circle (7) and visible by the client that started the transaction (shown at circle (8), such via access control type mechanisms that allow or disallow the use/inclusion of events from the transaction buffer based on whether the client is associated with particular transactions), the client 104 (or another client participating in the transaction) sends an end transaction request to the routing service 108, which is again routed to the transaction coordinator 110, which interacts with the relevant shards via their designated writers (interactions not shown) to commit the events in the transaction buffer at circles (9) and (10). If write conflicts are detected due to another ongoing transaction being in the process of updating the same events through the use of built-in OCC mechanism, or due to a condition supplied in one of the event condition expressions not being met, etc., the transaction is aborted, e.g., the events in the transaction buffer 112 are discarded. After all produced events to all shards are committed or aborted via circles (9) and (10), the transaction coordinator 110 writes the final transaction status (e.g., COMMITTED or ABORTED) to its transaction log 116, indicating that the transaction is complete. At circle (11), the client 104 is notified about the final transaction status.
Claim 17 is similar to claim 6. The claim is rejected based on the same reason
Claim 7
Claim 1 is included, Singh discloses wherein:
the transaction directive command is a commit command to perform a commit operation for the particular transaction (col 10, line 43-45, “… at 310, the client 104 may send an initialize (init) transaction request… to begin a transaction…” col 10, line 48-49, “… at 312… the init transaction request to a transaction coordinator…” <examiner note: as provided in extrinsic evidence, a transaction is set up by surrounding the SQL commands of the transaction with BEGIN, ROLLBACK, COMMIT commands. These command rollback and commit are transaction directive command for the transaction>),
the method comprises:
creating, by the leader server, a replication log record for a pre-commit operation in the replication pipeline (col 11, line 2-8, “… In a commit stage 306, the transaction coordinator 110 may attempt to commit the events of the transaction. The transaction coordinator 110 may update a transaction status of the metadata entry for the transaction in the transaction log 116 to be “committing” at 330. The transaction coordinator 110 also sends a “committing” command as shown at 332 to each identified designated writer for the involved shards in the transaction…”); and
in response to determining that there is consensus for the replication log record for the pre-commit operation, performing the commit operation on the particular transaction on the copy of the row of the table at the leader server and creating a replication log record for the commit operation in the replication pipeline (col 11, line 9-24, “… Each designated writer 120 thus determines whether it is possible to commit the events of the transaction… If everything is able to be written, each designated writer 120 returns a positive indication that all is good, shown as “can commit yes” at 334 and 336. When all responses back are positive… the transaction coordinator 110 can send a “commit” command 338 and 340 to the involved designated writers 120… Thus, the transaction coordinator 110 can update the transaction status in the transaction log 116 (e.g., to “committed”, possibly along with other metadata updates such as updating a last update time) at 348…”)
Claim 18 is similar to claim 7. The claim is rejected based on the same reason
Claim 8
Claim 7 is included, Singh further discloses the method comprising: in response to the leader server failing and becoming a new follower server, determining whether there is consensus for the replication log record for the pre-commit operation; in response to determining there is consensus, performing the commit operation on the particular transaction on the copy of the row of the table at the new follower server; and in response to determining there is no consensus, rolling back the particular transaction at the new follower server (col 17, line 13-27, “… In examples described herein, however, shards are append-only in nature and do not allow for direct updates of the events that are already committed as part of undo process during a transaction rollback. This inherent characteristic of any log-based data management makes aborting a transaction difficult to implement correctly, which is required to support atomicity. In addition, if the events for an ongoing transaction are directly committed to actual shards instead of the transaction buffer, the events committed will become observable to all consumers while the transaction is ongoing, which may result in concurrency issues due to the intermingled read and write of events across two or more concurrent transactions (serializable isolation violation) and incorrect and premature materialization of events by consumers…”)
Claim 19 is similar to claim 8. The claim is rejected based on the same reason.
Claim 9
Claim 1 is included, Singh discloses wherein: the command is a rollback command to perform a rollback operation for the particular transaction (col 10, line 43-45, “… at 310, the client 104 may send an initialize (init) transaction request… to begin a transaction…” col 10, line 48-49, “… at 312… the init transaction request to a transaction coordinator…” <examiner note: as provided in extrinsic evidence, a transaction is set up by surrounding the SQL commands of the transaction with BEGIN, ROLLBACK, COMMIT commands. These command rollback and commit are transaction directive command for the transaction>)
Claim 20 is similar to claim 9. The claim is rejected based on the same reason
Claim 10
Claim 1 is included, Singh discloses wherein: the replication log of each follower contains interleaved replication log records for uncommitted transactions, and the replication log records in the replication log for each follower server have strictly increasing log indices (fig. 3, committed, aborted, committing, open, …and log indices [Wingdings font/0xF3] TXN_ID strictly increasing)
Claim 11
Claim 1 is included, Singh discloses wherein each given follower server within the plurality of follower servers eagerly performs the change operation on its respective copy of the row of the table and appends the replication log record to its respective replication log in parallel (col 16, line 21-31, “… The designated writer node, upon receiving the COMMITTING requests, attempts to obtain locks for all of the events participating in the transaction belonging to that shard. If it can successfully do this, it can guarantee that there are no conflicting transactions, and even in the case of a crash, the cluster node can recover all the required state to complete the transaction. When the designated writer node receives the COMMIT request from the transaction coordinator, it is safe to write all of the changes to the shard. The designated writer node writes all of the events to the shard and releases all the acquired locks…’)
Claim 13
Claim 1 is included, Singh discloses wherein the replication log record comprises a logical change record for the change operation, a valid log index, and a term (fig. 3, change operation [Wingdings font/0xF3] committed, aborted…, valid log index [Wingdings font/0xF3] TXN_ID, term [Wingdings font/0xF3] A, B, …)
Claim 14
Claim 1 is included, Park discloses further comprising calling an append entries Remote Procedure Call (RPC) to propagate replication log records in the replication log to the plurality of follower servers ([0055], “… The source system 210 also comprises a replication handler 218 for handling write log entries in the write log queue 214. The replication handler 218 can take write logs from the write log queue 214 and send them to one or more replica nodes (e.g., node 220 and/or node 230) in order for the replica nodes to perform replication by executing the DML statements contained within the write log entries. For example, the replication handler 218 can retrieve a write log entry from the write log queue 214 and send the write log entry to node 220 and/or to node 230. The write log entry can pass through various internal or external structures, queues, etc., when it is routed to the replica nodes…”)
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park (U.S. Pub 2016/0371357, in view of Singh (U.S. Patent 11874822 B1), as applied to claim 2, and further in view of Schreter (U.S. Pub 2022/0391382 A1)
Claim 4
Claim 2 is included, however, Park and Singh do not explicitly disclose further discloses the method further comprising: in response to the leader server receiving acknowledgement that the replication log record for the commit operation has been appended to the replication log of the consensus number of the plurality of follower servers, advancing, by the leader server, a commit index.
Schreter discloses in response to the leader server receiving acknowledgement that the replication log record for the commit operation has been appended to the replication log of the consensus number of the plurality of follower servers, advancing, by the leader server, a commit index ([0090], line 1-10, “… At 504, the transaction coordinator may send a prepare request to all participating data partitions to prepare to commit the transaction… If a data partition determines that the transaction may be committed… inform the transaction coordinator…” [0091], line 8-11, “… the transaction coordinator may determine that every data partition request to commit the transaction. Accordingly, at 510, the transaction coordinator may generate a commit identifier…” Table 1, “… commit_id is the ID set at the commit time for a committed transaction… this can be a globally monotonically increasing ID given out by the sequencer of the transaction domain…”)
Park and Singh disclose distributed transactions are committed in leader and follower nodes based on consensus protocol. However, Park and Singh do not disclose the feature of “advancing by the leader server, a commit index in response to receiving acknowledgement from a number of follower servers. Schreter discloses the commit_id is generated as a globally monotonically increasing ID. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include setting commit_ID as disclosed by Schreter into Singh because this commit_ID is set at the commit time for a committed transaction, which can be used to implement isolation in ACID.
Claim(s) 12 is rejected under 35 U.S.C. 103 as being unpatentable over Park (U.S. Pub 2016/0371357, in view of Singh (U.S. Patent 11874822 B1), as applied to claim 1, and further in view of Lee (U.S. Pub 2018/0349430 A1)
Claim 12
Claim 1 is included, however, Park and Singh do not disclose wherein each given follower server within the plurality of follower servers is configured to redirect commands from the client to the leader server.
Lee discloses wherein each given follower server within the plurality of follower servers is configured to redirect commands from the client to the leader server ([0091], “… the database client 502 connects with worker node 512 to execute a plurality of operations… if the worker node 512 does not host the relevant data, the worker node can forward the request to another node (e.g., the coordinator node 506…)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of forwarding client request to the leader node as disclosed by Lee into because in case of the client issue transaction at the follower node and the follower nodes do not have relevant data, the forwarding feature allow coordinator to execute client commands and return the result to the client.
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.
Claim 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 12277140 in view of Park (U.S. Pub 2016/0371357. The rejections are explained as below
Application: 19062275
Patent: 12277140
Claim 1
A computer-implemented method comprising:
receiving, from a client at a leader server, a command to perform a change operation on a row of a table of a database, wherein:
the row of the table is replicated on a replication group of servers such that each server within the replication group of servers stores a respective copy of the row of the table,
the command is associated with a particular transaction,
the replication group of servers includes the leader server and a plurality of follower servers, and
the leader server is configured to perform data manipulation language (DML) operations on the row of the table and replicate the DML operations to the plurality of follower servers;
performing, by the leader server, the change operation on the copy of the row of the table stored at the leader server;
in response to the leader server performing the change operation, creating, by the leader server, a replication log record for the change operation in a replication pipeline to be replicated to the plurality of follower servers asynchronously;
in response to the leader server creating the replication log record for the change operation in the replication pipeline, returning a result of the change operation from the leader server to the client;
receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction; and
creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol,
wherein the method is performed by one or more computing devices.
Claim 1
A computer-implemented method comprising:
receiving, at a leader server from a client, a command to perform a change operation on a row of a table of a database, wherein:
the row of the table is replicated on a replication group of servers such that each server within the replication group of servers stores a respective copy of the row of the table,
the replication group of servers includes the leader server and one or more follower servers, and
the leader server is configured to perform data manipulation language (DML) operations on the row of the table and replicate the DML operations to the one or more follower servers;
performing, by the leader server, the change operation on the copy of the row of the table stored at the leader server;
in response to the leader server performing the change operation, creating, by the leader server, a replication log record for the change operation in a replication pipeline to be replicated to the one or more follower servers asynchronously; and
in response to the leader server creating the replication log record for the change operation in the replication pipeline, returning a result of the change operation from the leader server to the client;
subsequent to returning the result to the client, tracking, by the leader server, whether the replication log record is replicated to a replication pipeline of a consensus number of follower servers;
wherein the method is performed by one or more computing devices.
However, Patent ‘140 does not feature
the command is associated with a particular transaction
receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction; and
creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol,
Singh discloses
the command is associated with a particular transaction (col 10, line 43-45, “… at 310, the client 104 may send an initialize (init) transaction request… to begin a transaction…” col 10, line 48-49, “… at 312… the init transaction request to a transaction coordinator…” col 20, line 50-67 <examiner note: as provided in extrinsic evidence, a transaction is set up by surrounding the SQL commands of the transaction with BEGIN, ROLLBACK, COMMIT commands. These command rollback and commit are transaction directive command for the transaction>)
receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction (col 10, line 43-45, “… at 310, the client 104 may send an initialize (init) transaction request… to begin a transaction…” col 10, line 48-49, “… at 312… the init transaction request to a transaction coordinator…” col 20, line 50-67 <examiner note: as provided in extrinsic evidence, a transaction is set up by surrounding the SQL commands of the transaction with BEGIN, ROLLBACK, COMMIT commands. These command rollback and commit are transaction directive command for the transaction>); and
creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol (col 10, line 53-55, “… at 314, the transaction coordinator 110 allocates a transaction identifier for the transaction… and persist… in the transaction log 116, e.g., along with other relevant transaction metadata…” <examiner note: transaction log 116 in fig. 1 shows status of the transaction as committed aborted committing, open…> col 11, line 5-25, “… The transaction coordinator 110 also sends a “committing” command as shown at 332 to each identified designated writer for the involved shards in the transaction… Each designated writer 120 thus determines whether it is possible to commit the events of the transaction from its perspective… If everything is able to be written, each designated writer 120 returns a positive indication that all is good… When all responses back are positive… the transaction coordinator 110 can send a “commit” command 338 and 340 to the involved designated writers 120, which commit the events at 342, and return success messages at 344 and 346. Thus, the transaction coordinator 110 can update the transaction status in the transaction log 116 (e.g., to “committed”, possibly along with other metadata updates such as updating a last update time) at 348 and return an indication of the status (e.g., success) to the client 104…”)
Park discloses DML operations are performed transactions and log shipping are implemented in distributed database. However, Park does not explicitly disclose receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction and creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol. Singh discloses a transaction coordinator and transaction buffer to support running ACID transaction across multiple streams spanning multiple shards. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporating the transactional eventing service with built in support for event conditions that allow users to place conditions that must be met in order for events to be accepted into the store, and optimistic concurrency control to guarantee write consistency by preventing users from accidentally overwriting changes that were made by others.
Claim 2
The method of claim 1, wherein:
the transaction directive command is a commit command to perform a commit operation for the particular transaction,
the method further comprises:
in response to the leader server receiving acknowledgement that the replication log record for the commit operation has been appended to a replication log of a consensus number of the plurality of follower servers, performing the commit operation on the particular transaction on the copy of the row of the table at the leader server; and
returning a result of the commit operation to the client.
Claim 2
The method of claim 1, wherein:
the command is associated with a particular transaction,
the method further comprises:
receiving, from the client at the leader server, a commit command to perform a commit operation on the particular transaction;
creating, by the leader server, a replication log record for the commit operation in the replication pipeline; in response to the leader server receiving acknowledgement that the replication log record for the commit operation has been appended to a replication log of a consensus number of the one or more follower servers, performing the commit operation on the particular transaction on the copy of the row of the table at the leader server; and
returning a result of the commit operation to the client.
Claim 3
The method of claim 2, wherein a given acknowledgement received from a given follower server includes multiple transaction commits.
Claim 3
The method of claim 2, wherein a given acknowledgement received from a given follower server includes multiple transaction commits.
Claim 4
The method of claim 2, the method further comprising: in response to the leader server receiving acknowledgement that the replication log record for the commit operation has been appended to the replication log of the consensus number of the plurality of follower servers, advancing, by the leader server, a commit index.
Claim 4
The method of claim 2, the method further comprising: in response to the leader server receiving acknowledgement that the replication log record for the commit operation has been appended to the replication log of the consensus number of the one or more follower servers, advancing, by the leader server, a commit index.
Claim 5
The method of claim 2, wherein performing the commit operation comprises writing log records for the particular transaction to disk.
Claim 5
The method of claim 2, wherein performing the commit operation comprises writing log records for the particular transaction to disk.
Claim 6
The method of claim 1, wherein:
the transaction directive command is a commit command to perform a commit operation for the particular transaction,
the method further comprises:
preparing the particular transaction for commit at the leader server;
marking the particular transaction as in-doubt;
in response to the leader server failing and becoming a new follower server,
determining whether there is consensus that the replication log record for the commit operation has been appended to a replication log of a consensus number of the plurality of follower servers;
in response to determining there is consensus, performing the commit operation on the particular transaction on the copy of the row of the table at the new follower server; and
in response to determining there is no consensus, rolling back the particular transaction at the new follower server.
Claim 6
The method of claim 1, wherein:
the command is associated with a particular transaction, the method further comprises: receiving, from the client at the leader server, a commit command to perform a commit operation on the particular transaction;
preparing the particular transaction for commit at the leader server;
marking the particular transaction as in-doubt;
creating, by the leader server, a replication log record for the commit operation in the replication pipeline;
in response to the leader server failing and becoming a new follower server, determining whether there is consensus that the replication log record for the commit operation has been appended to a replication log of a consensus number of the one or more follower servers;
in response to determining there is consensus, performing the commit operation on the particular transaction on the copy of the row of the table at the new follower server; and
in response to determining there is no consensus, rolling back the particular transaction at the new follower server.
Claim 7
The method of claim 1, wherein:
the transaction directive command is a commit command to perform a commit operation for the particular transaction,
the method comprises:
creating, by the leader server, a replication log record for a pre-commit operation in the replication pipeline; and
in response to determining that there is consensus for the replication log record for the pre-commit operation, performing the commit operation on the particular transaction on the copy of the row of the table at the leader server and creating a replication log record for the commit operation in the replication pipeline.
Claim 7
The method of claim 1, wherein:
the command is associated with a particular transaction, the method comprises: receiving, from the client at the leader server, a commit command to perform a commit operation on the particular transaction;
creating, by the leader server, a replication log record for a pre-commit operation in the replication pipeline; and
in response to determining that there is consensus for the replication log record for the pre-commit operation, performing the commit operation on the particular transaction on the copy of the row of the table at the leader server and creating a replication log record for the commit operation in the replication pipeline.
Claim 8
The method of claim 7, the method comprising: in response to the leader server failing and becoming a new follower server, determining whether there is consensus for the replication log record for the pre-commit operation; in response to determining there is consensus, performing the commit operation on the particular transaction on the copy of the row of the table at the new follower server; and in response to determining there is no consensus, rolling back the particular transaction at the new follower server.
Claim 8
The method of claim 7, the method comprising: in response to the leader server failing and becoming a new follower server, determining whether there is consensus for the replication log record for the pre-commit operation; in response to determining there is consensus, performing the commit operation on the particular transaction on the copy of the row of the table at the new follower server; and in response to determining there is no consensus, rolling back the particular transaction at the new follower server.
Claim 9
The method of claim 1, wherein: the command is a rollback command to perform a rollback operation for the particular transaction.
Claim 9
The method of claim 1, wherein: the command is associated with a particular transaction, the method further comprises: receiving, from the client at the leader server, a rollback command to perform a rollback operation on the particular transaction; and creating, by the leader server, a replication log record for the rollback operation in the replication pipeline.
Claim 10
The method of claim 1, wherein: the replication log of each follower contains interleaved replication log records for uncommitted transactions, and the replication log records in the replication log for each follower server have strictly increasing log indices.
Claim 10
The method of claim 1, wherein: the replication log of each follower contains interleaved replication log records for uncommitted transactions, and the replication log records in the replication log for each follower server have strictly increasing log indices.
Claim 11
The method of claim 1, wherein each given follower server within the plurality of follower servers eagerly performs the change operation on its respective copy of the row of the table and appends the replication log record to its respective replication log in parallel.
Claim 11
The method of claim 1, wherein each given follower server within the one or more follower servers eagerly performs the change operation on its respective copy of the row of the table and appends the replication log record to its respective replication log in parallel.
Claim 12
The method of claim 1, wherein each given follower server within the plurality of follower servers is configured to redirect commands from the client to the leader server.
Claim 12
The method of claim 1, wherein each given follower server within the one or more follower servers is configured to redirect commands from the client to the leader server.
Claim 13
The method of claim 1, wherein the replication log record comprises a logical change record for the change operation, a valid log index, and a term.
Claim 13
The method of claim 1, wherein the replication log record comprises a logical change record for the change operation, a valid log index, and a term.
Claim 14
The method of claim 1, further comprising calling an append entries Remote Procedure Call (RPC) to propagate replication log records in the replication log to the plurality of follower servers.
Claim 14
The method of claim 1, further comprising calling an append entries Remote Procedure Call (RPC) to propagate replication log records in the replication log to the one or more follower servers.
Claim 15
One or more non-transitory storage media storing instructions which, when executed by one or more computing devices, cause:
receiving, from a client at a leader server, a command to perform a change operation on a row of a table of a database, wherein:
the row of the table is replicated on a replication group of servers such that each server within the replication group of servers stores a respective copy of the row of the table,
the command is associated with a particular transaction,
the replication group of servers includes the leader server and a plurality of follower servers, and
the leader server is configured to perform data manipulation language (DML) operations on the row of the table and replicate the DML operations to the plurality of follower servers;
performing, by the leader server, the change operation on the copy of the row of the table stored at the leader server;
in response to the leader server performing the change operation, creating, by the leader server, a replication log record for the change operation in a replication pipeline to be replicated to the plurality of follower servers asynchronously;
in response to the leader server creating the replication log record for the change operation in the replication pipeline, returning a result of the change operation from the leader server to the client;
receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction; and
creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol.
Claim 15
One or more non-transitory storage media storing instructions which, when executed by one or more computing devices, cause:
receiving, at a leader server from a client, a command to perform a change operation on a row of a table of a database, wherein:
the row of the table is replicated on a replication group of servers such that each server within the replication group of servers stores a respective copy of the row of the table,
the replication group of servers includes the leader server and one or more follower servers, and
the leader server is configured to perform data manipulation language (DML) operations on the row of the table and replicate the DML operations to the one or more follower servers;
performing, by the leader server, the change operation on the copy of the row of the table stored at the leader server;
in response to the leader server performing the change operation, creating, by the leader server, a replication log record for the change operation in a replication pipeline to be replicated to the one or more follower servers asynchronously; and
in response to the leader server creating the replication log record for the change operation in the replication pipeline, returning a result of the change operation from the leader server to the client
subsequent to returning the result to the client, tracking, by the leader server, whether the replication log record is replicated to a replication pipeline of a consensus number of follower servers.
However, Patent ‘140 does not feature
the command is associated with a particular transaction
receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction; and
creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol,
Singh discloses
the command is associated with a particular transaction (col 10, line 43-45, “… at 310, the client 104 may send an initialize (init) transaction request… to begin a transaction…” col 10, line 48-49, “… at 312… the init transaction request to a transaction coordinator…” col 20, line 50-67 <examiner note: as provided in extrinsic evidence, a transaction is set up by surrounding the SQL commands of the transaction with BEGIN, ROLLBACK, COMMIT commands. These command rollback and commit are transaction directive command for the transaction>)
receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction (col 10, line 43-45, “… at 310, the client 104 may send an initialize (init) transaction request… to begin a transaction…” col 10, line 48-49, “… at 312… the init transaction request to a transaction coordinator…” col 20, line 50-67 <examiner note: as provided in extrinsic evidence, a transaction is set up by surrounding the SQL commands of the transaction with BEGIN, ROLLBACK, COMMIT commands. These command rollback and commit are transaction directive command for the transaction>); and
creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol (col 10, line 53-55, “… at 314, the transaction coordinator 110 allocates a transaction identifier for the transaction… and persist… in the transaction log 116, e.g., along with other relevant transaction metadata…” <examiner note: transaction log 116 in fig. 1 shows status of the transaction as committed aborted committing, open…> col 11, line 5-25, “… The transaction coordinator 110 also sends a “committing” command as shown at 332 to each identified designated writer for the involved shards in the transaction… Each designated writer 120 thus determines whether it is possible to commit the events of the transaction from its perspective… If everything is able to be written, each designated writer 120 returns a positive indication that all is good… When all responses back are positive… the transaction coordinator 110 can send a “commit” command 338 and 340 to the involved designated writers 120, which commit the events at 342, and return success messages at 344 and 346. Thus, the transaction coordinator 110 can update the transaction status in the transaction log 116 (e.g., to “committed”, possibly along with other metadata updates such as updating a last update time) at 348 and return an indication of the status (e.g., success) to the client 104…”)
Park discloses DML operations are performed transactions and log shipping are implemented in distributed database. However, Park does not explicitly disclose receiving, from the client at the leader server, a transaction directive command to perform a transaction directive operation for the particular transaction and creating, by the leader server, a replication log record for the transaction directive operation in the replication pipeline to be replicated to the plurality of follower servers based on a consensus protocol. Singh discloses a transaction coordinator and transaction buffer to support running ACID transaction across multiple streams spanning multiple shards. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporating the transactional eventing service with built in support for event conditions that allow users to place conditions that must be met in order for events to be accepted into the store, and optimistic concurrency control to guarantee write consistency by preventing users from accidentally overwriting changes that were made by others.
Claim 16
The one or more non-transitory storage media of claim 15, wherein:
the transaction directive command is a commit command to perform a commit operation for the particular transaction,
the instructions, when executed by the one or more computing devices, further cause:
in response to the leader server receiving acknowledgement that the replication log record for the commit operation has been appended to a replication log of a consensus number of the plurality of follower servers, performing the commit operation on the particular transaction on the copy of the row of the table at the leader server; and
returning a result of the commit operation to the client.
Claim 16
The one or more non-transitory storage media of claim 15, wherein:
the command is associated with a particular transaction, the instructions further cause: receiving, from the client at the leader server, a commit command to perform a commit operation on the particular transaction;
creating, by the leader server, a replication log record for the commit operation in the replication pipeline;
in response to the leader server receiving acknowledgement that the replication log record for the commit operation has been appended to a replication log of a consensus number of the one or more follower servers, performing the commit operation on the particular transaction on the copy of the row of the table at the leader server; and
returning a result of the commit operation to the client.
Claim 17
The one or more non-transitory storage media of claim 15, wherein:
the transaction directive command is a commit command to perform a commit operation for the particular transaction,
the instructions, when executed by the one or more computing devices, further cause:
preparing the particular transaction for commit at the leader server;
marking the particular transaction as in-doubt;
in response to the leader server failing and becoming a new follower server, determining whether there is consensus that the replication log record for the commit operation has been appended to a replication log of a consensus number of the plurality of follower servers;
in response to determining there is consensus, performing the commit operation on the particular transaction on the copy of the row of the table at the new follower server; and
in response to determining there is no consensus, rolling back the particular transaction at the new follower server.
Claim 17
The one or more non-transitory storage media of claim 15, wherein:
the command is associated with a particular transaction, the instructions further cause: receiving, from the client at the leader server, a commit command to perform a commit operation on the particular transaction;
preparing the particular transaction for commit at the leader server;
marking the particular transaction as in-doubt;
creating, by the leader server, a replication log record for the commit operation in the replication pipeline;
in response to the leader server failing and becoming a new follower server, determining whether there is consensus that the replication log record for the commit operation has been appended to a replication log of a consensus number of the one or more follower servers;
in response to determining there is consensus, performing the commit operation on the particular transaction on the copy of the row of the table at the new follower server; and
in response to determining there is no consensus, rolling back the particular transaction at the new follower server.
Claim 18
The one or more non-transitory storage media of claim 15, wherein:
the transaction directive command is a commit command to perform a commit operation for the particular transaction,
the instructions, when executed by the one or more computing devices, further cause:
creating, by the leader server, a replication log record for a pre-commit operation in the replication pipeline; and
in response to determining that there is consensus for the replication log record for the pre-commit operation, performing the commit operation on the particular transaction on the copy of the row of the table at the leader server and creating a replication log record for the commit operation in the replication pipeline.
Claim 18
The one or more non-transitory storage media of claim 15, wherein:
the command is associated with a particular transaction, the instructions further cause: receiving, from the client at the leader server, a commit command to perform a commit operation on the particular transaction;
creating, by the leader server, a replication log record for a pre-commit operation in the replication pipeline; and
in response to determining that there is consensus for the replication log record for the pre-commit operation, performing the commit operation on the particular transaction on the copy of the row of the table at the leader server and creating a replication log record for the commit operation in the replication pipeline.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAU HAI HOANG whose telephone number is (571)270-5894. The examiner can normally be reached 1st biwk: Mon-Thurs 7:00 AM-5:00 PM; 2nd biwk: Mon-Thurs: 7:00 am-5:00pm, Fri: 7:00 am - 4:00pm.
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, Robert Beausoliel can be reached at 571 262 3645. 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.
HAU HAI. HOANG
Primary Examiner
Art Unit 2167
/HAU H HOANG/Primary Examiner, Art Unit 2167