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
Applicant’s Amendments, filed March 26, 2026 have been entered. Claims 1, 5, 11, 15, and 18 have been amended, and claims 1-20 are currently pending.
Response to Arguments
Applicant’s arguments, see Remarks pp. 12-15, filed March 26, 2026, with respect to the rejections of claims 1-20 under 35 U.S.C. 102 and 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Lahiri et al. (Pub. No. US 2020/0125457 A1, hereinafter “Lahiri”).
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 factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 7, 8, 11-13 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (Pub. No. US 2018/0349430 A1, hereinafter “Lee”) in view of Lahiri et al. (Pub. No. US 2020/0125457 A1, hereinafter “Lahiri”).
Regarding claim 1, Lee teaches:
physical computing nodes implementing a transaction coordinator and transaction participants of a target transaction, wherein each transaction participant of the transaction participants records a demarcation location, (Lee – Fig. 6 present a system having a database client 502, a coordinator node 506 (i.e. transaction coordinator) and worker nodes 512, 516 (i.e. transaction participants). The system illustrates how a transaction having one or more write operations commits [0090]. The transaction commit is written by worker nodes to persistent storage, such as in a commit log (i.e. records a demarcation location) [0098].)
and the demarcation location indicates that in a transaction sequence formed by transactions processed by corresponding transaction participants, transactions preceding the demarcation location are in a settled state (Lee – if there is neither a precommit nor a commit log entry at worker node 512, 516, then the transaction can be rolled back at the worker node without asking the coordinator node 506 [0102]. Examiner interprets that the commit log entry (i.e. demarcation location) indicates transactions preceding the commit log entry are in a settled state because rolling back to the previous transaction indicates that the previous transaction is considered valid and completed.)
wherein the transaction coordinator is configured to: initiate a preparation request for the target transaction to the transaction participant to cause each of the transaction participants to generate and persistently store a preparation log corresponding to the target transaction (Lee – the commit protocol begins at 520, where the database client 502 sends a request to commit a transaction (i.e. target transaction) to the worker node 512 in a communication 522. The worker node 512 receives a request at 524 and sends the commit request to the coordinator node 506 in communication 526. The coordinator node 506 initiates the commit process at 528, and sends communications 530 to the worker nodes 512, 516 (i.e. preparation request) to prepare the worker nodes (i.e. transaction participant) for the transaction commit. In precommit blocks 532, each worker node 512, 516 executes SetAsPrepared to precommit the transaction, assigning the transaction the LCT currently maintained at the worker node. The worker nodes 512, 516 then write the transaction to persistent storage, such as in a precommit log (i.e. preparation log), in block 534 [0093-0094].)
and initiate a transaction execution request corresponding to the corresponding target transaction to the transaction participant based on persistence results returned by the transaction participants for the preparation log (Lee – the worker nodes 512, 516 then communicate with the coordinator node 502, via notifications 536, indicating that the transaction has been precommitted at the worker nodes (i.e. persistence results returned) and confirming to the coordinator about the commit readiness of the worker nodes [0094]. When the coordinator node 506 receives the notifications 536, at 540, the coordinator node precommits the transaction. Once the coordinator node 506 has precommited the transaction, the coordinator node sends communications 546 to the worker nodes 512, 516 (i.e. transaction execution request) indicating the precommitment [0095].)
and wherein each of the transaction participants is configured to: generate a preparation log in response to the preparation request; persistently store the preparation log (Lee – the commit protocol begins at 520, where the database client 502 sends a request to commit a transaction (i.e. target transaction) to the worker node 512 in a communication 522. The worker node 512 receives a request at 524 and sends the commit request to the coordinator node 506 in communication 526. The coordinator node 506 initiates the commit process at 528, and sends communications 530 to the worker nodes 512, 516 (i.e. preparation request) to prepare the worker nodes (i.e. transaction participant) for the transaction commit. In precommit blocks 532, each worker node 512, 516 executes SetAsPrepared to precommit the transaction, assigning the transaction the LCT currently maintained at the worker node. The worker nodes 512, 516 then write the transaction to persistent storage, such as in a precommit log (i.e. preparation log), in block 534 [0093-0094].)
return a persistence result to the transaction coordinator (Lee – the worker nodes 512, 516 then communicate with the coordinator node 502, via notifications 536, indicating that the transaction has been precommitted at the worker nodes (i.e. persistence results returned) and confirming to the coordinator about the commit readiness of the worker nodes [0094]. When the coordinator node 506 receives the notifications 536, at 540, the coordinator node precommits the transaction. Once the coordinator node 506 has precommited the transaction, the coordinator node sends communications 546 to the worker nodes 512, 516 (i.e. transaction execution request) indicating the precommitment [0095].)
perform a transaction operation on the target transaction in response to the transaction execution request, (Lee – each worker node 512, 516, after completing block 550, sends a communication 556 to the coordinator node 506, indicating that the new transaction was successfully assigned a new CID at the worker node. While the communications 546, and the increment and assign functions at 550, are being carried out, the coordinator node 506 writes the commit to persistent storage at 552, such as to a commit log. The coordinator node 506 sends communications 566 to the worker nodes 512, 516 that the transaction has been committed by the coordinator node. When the worker nodes 512, 516 receive the communication 566, the worker nodes commit the transaction (i.e. perform a transaction operation) and release their record or table locks at 570 [0096-0098].)
wherein the transaction operation comprises a transaction commitment operation based on the demarcation location (Lee – once the coordinator node has precommitted the transaction, including assigning the CID, the coordinator node sends communications to the worker nodes 512, 516 indicating the precommitment and associated CID. The worker nodes 512, 516 then increment their locally maintained LCT values at Fig. 5, 550. In a particular example, the worker nodes 512, 516 select as the new LCT value the larger of the current LCT value maintained at the worker node (i.e. demarcation location) and the CID for the transaction received from the coordinator node in communication 546. The worker nodes 512, 516 then assign the new LCT value as the CID for the transaction [0095]. See [0070] Table 1, where LCT is the CTS (transaction commit timestamp of a transaction manager, incremented when a write transaction commits) at a worker node i. Examiner interprets that the LCT is the demarcation location indicating the last successful commit, and the new LCT value is created as a result of the transaction operation based on the current LCT value.)
wherein, when an abnormality occurs and is recovered, the transaction participant is further configured to read and play back the persistently stored preparation log to restore a transaction in the transaction sequence, read the demarcation location, and perform the transaction commitment operation on a transaction preceding the demarcation location in the transaction sequence (Lee – even if a worker node 512, 516 crashes (i.e. abnormality occurs) without having written its local commit log, the transaction can be detected as an in-doubt transaction during its restart and thus it can be committed again by referring to the coordinator node 506. If there is neither a precommit nor a commit log entry at worker node 512, 516, then the transaction can be rolled back at the worker node without asking the coordinator node 506 [0102]. Also see [0094-0098], where specifically in [0095] the workers nodes increment their locally maintained LCY values once the coordinator node has precommitted the transaction, assign the new LCT value as the CID for the transaction, communicate to the coordinator node that the new CID was assigned at the worker node, and the coordinator node writes the commit to persistent storage. Examiner interprets that where there is a crash after the coordinator node writes the commit to persistent storage, the worker node is able to read the LCT (i.e. demarcation location) to determine the last committed transaction at the coordinator node and then rollback by utilizing the LCT, which is the new CID that the coordinator node uses for executing WriteCommitLog.)
Lee does not appear to teach:
wherein the transaction commitment operation is performed exclusively in the memory and does not include persistently storing a commitment log in the non-volatile storage device for the target transaction, thereby reducing time consumption for transaction commitment compared to a two-phase commitment process requiring persistent storage of a commitment log; and switch the target transaction from an unsettled state to the settled state in the memory after performing the transaction operation,
without referring to the transaction coordinator
However, Lahiri teaches:
wherein the transaction commitment operation is performed exclusively in the memory and does not include persistently storing a commitment log in the non-volatile storage device for the target transaction, thereby reducing time consumption for transaction commitment compared to a two-phase commitment process requiring persistent storage of a commitment log; and switch the target transaction from an unsettled state to the settled state in the memory after performing the transaction operation, (Lahiri – changes to database 108 are recorded in change records in change logs. Change records are staged in log buffers, from where the system daemon writes change records to change logs. Log buffers are stored in NVRAM. Storing log buffers in NVRAM enables faster durable commits. A transaction is durably committed when a change record, referred to as a commit record, is durably stored. By using NVRAM to store log buffers, a transaction is durably committed when the commit record is written to the log buffer (i.e. settled state), rather than when written to change logs, which can take much longer [0026-0028].)
without referring to the transaction coordinator (Lahiri – changes to database 108 are recorded in change records in change logs. Change records are staged in log buffers, from where the system daemon writes change records to change logs. Log buffers are stored in NVRAM. Storing log buffers in NVRAM enables faster durable commits. A transaction is durably committed when a change record, referred to as a commit record, is durably stored. By using NVRAM to store log buffers, a transaction is durably committed when the commit record is written to the log buffer (i.e. settled state), rather than when written to change logs, which can take much longer [0026-0028].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Lee and Lahiri before them, to modify the system of Lee with the teachings of Lahiri, as indicated above. One would have been motivated to make such a modification to reduce the time of recovery for a system failure (Lahiri [0006-0007]).
Claims 11 and 18 correspond to claim 1 and are rejected accordingly.
Regarding claim 2, Lee teaches:
wherein the transaction participant corresponds to a plurality of replicas in the distributed system, wherein persistently store the preparation log by the transaction participant comprises persistently store the preparation log for each of the plurality of replicas, and wherein the persistence result is associated with a percentage of replicas in the plurality of replicas that persistently storing the preparation log is successfully performed (Lee –in precommit blocks 532, each worker node 512, 516 (i.e. each of the plurality of replicas) executes SetAsPrepared to precommit the transaction, assigning the transaction the LCT currently maintained at the worker node. The worker nodes 512, 516 (i.e. each of the plurality of replicas) then write the transaction to persistent storage, such as in a precommit log (i.e. preparation log), in block 534. The worker nodes 512, 516 then communicate with the coordinator node 502, via notifications 536, indicating that the transaction has been precommitted at the worker nodes and confirming to the coordinator about the commit readiness of the worker nodes [0094]. Examiner interprets that all the worker nodes (100%) must persistently store the preparation log and return a persistence result to the coordinator in order to confirm commit readiness to the coordinator.)
Claims 12 and 19 corresponds to claim 2 and is rejected accordingly.
Regarding claim 3, Lee teaches:
further comprising a master node and one or more slave nodes, a master replica of the transaction participant is deployed on the master node, a slave replica of the transaction participant is deployed on the one or more slave nodes, the master replica is used for data access, and the slave replica is used for data backup (Lee – the database client can communicate with a coordinator (or master) node 220 and one or more worker (or slave) nodes 230. In some cases, a node 220, 230 can include a table that is a replica of a table maintained on another node (e.g. where one table serves as a source table and another table serves as a replica table, such as when replicating data at multiple nodes is desired for providing high availability of data, such as to guard against failure of a node or in a scale out environment to improve system responsiveness). Examiner interprets that a master replica is deployed on the master node, and a slave replica is deployed on the slave node.)
and wherein the persistently storing the preparation log comprises: sending, by the master replica, the preparation log to a transaction status manager of the master node for the transaction status manager to write the preparation log into a transaction buffer; and persistently storing, by the transaction buffer, the preparation log in the master replica and the slave replica (Lee – each node has its own persistency store for the results of persistency operations (e.g., log and checkpoint files) [0044]. The commit protocol begins at 520, where the database client 502 sends a request to commit a transaction to the worker node 512 (i.e. deployed slave replica on slave node) in a communication 522. The worker node 512 receives a request at 524 and sends the commit request to the coordinator node 506 in communication 526. The coordinator node 506 (i.e. master node) initiates the commit process at 528, and sends communications 530 to the worker nodes 512, 516 to prepare the worker nodes for the transaction commit. In precommit blocks 532, each worker node 512, 516 executes SetAsPrepared to precommit the transaction, assigning the transaction the LCT currently maintained at the worker node. The worker nodes 512, 516 then write the transaction to persistent storage (i.e. slave replica), such as in a precommit log (i.e. preparation log), in block 534 [0093-0094]. When the coordinator node 506 receives the notifications 536, at 540, the coordinator node precommits the transaction, assigning the transaction a pCID equal to the current GCT maintained by the coordinator node. Once the coordinator node has precommited the transaction, including assigning the CID, the coordinator node sends communications to the worker node [0095]. The memory (i.e. transaction buffer) 1120, 1125 stores software implementing one or more innovations described herein, and can also store the list of nodes to be included in commit operations for a transaction [0142].)
Claims 13 and 20 correspond to claim 3 and are rejected accordingly.
Regarding claim 7, Lee teaches:
wherein the performing a transaction operation corresponding to the transaction execution request comprises: performing, by the transaction participant, a corresponding transaction commitment operation when the transaction execution request is a transaction commitment request; or generating and persistently storing, by the transaction participant, a transaction rollback log and performing a corresponding transaction rollback operation in response to determining that the transaction execution request is a transaction rollback request (Lee – the commit protocol begins at 520, where the database client 502 sends a request to commit a transaction (i.e. transaction commitment request) to the worker node 512 in a communication 522. [0093]. Each worker node 512, 516, after completing block 550, sends a communication 556 to the coordinator node 506, indicating that the new transaction was successfully assigned a new CID at the worker node. While the communications 546, and the increment and assign functions at 550, are being carried out, the coordinator node 506 writes the commit to persistent storage at 552, such as to a commit log. The coordinator node 506 sends communications 566 to the worker nodes 512, 516 that the transaction has been committed by the coordinator node. When the worker nodes 512, 516 receive the communication 566, the worker nodes commit the transaction (i.e. perform a transaction commitment operation) and release their record or table locks at 570. The transaction commit is then written by the worker nodes 512, 516 to persistent storage, such as commit log, at 572 (i.e. switch to settled state) [0096-0098].
and the transaction participant is further configured to: when an abnormality occurs and is recovered, reading and playing back the persistently stored preparation log to restore a transaction in the transaction sequence; reading and playing back the persistently stored transaction rollback log to perform the transaction rollback operation on the corresponding transaction in the transaction sequence; and reading the demarcation location and performing the transaction commitment operation on a transaction preceding the demarcation location in the transaction sequence (Lee – even if a worker node 512, 516 crashes (i.e. abnormality occurs) without having written its local commit log, the transaction can be detected as an in-doubt transaction during its restart and thus it can be committed again by referring to the coordinator node 506. If there is neither a precommit nor a commit log entry at worker node 512, 516, then the transaction can be rolled back at the worker node without asking the coordinator node 506 [0102].)
Claim 17 corresponds to claim 7 and is rejected accordingly.
Regarding claim 8, Lee teaches:
wherein the demarcation location is stored in a predetermined recording log or the preparation log (Lee – the transaction commit is written by worker nodes to persistent storage, such as in a commit log (i.e. predetermined recording log which stores the demarcation location) [0098].)
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Lahiri in view of KR101713537B1 (KR101713537B1, CHA MIN KYOO, HAN SEUNG HOO, LEE KYU JAE, 2014, hereinafter “KR1017”).
Regarding claim 4, Lee teaches:
wherein master replicas of at least two transaction participants are deployed on the master node, and slave replicas of the at least two transaction participants are deployed on at least one slave node of the one or more slave nodes (Lee – the database client 210 can communicate with a coordinator (or master) node 220 and one or more worker (or slave) nodes 230. A node 220, 230 can include a table that is a replica of a table maintained on another node (e.g., where one table serves as a source table and another table serves as a replica table, such as when replicating data at multiple nodes is desired for providing high availability of data, such as to guard against failure of a node, or in a scale out environment to improve system responsiveness [0045].)
Lee modified by Lahiri does not appear to teach:
and wherein persistently storing the preparation log comprises: sending, by the master replicas of the at least two transaction participants, the preparation logs to the transaction status manager of the master node for the transaction status manager to write the preparation logs into a target transaction buffer; persistently storing, by the target transaction buffer, the preparation logs written by the at least two transaction participants in the corresponding master replicas; and synchronizing the preparation logs in batches to the at least one slave node to be persistently stored to the corresponding slave replicas
However, KR1017 teaches:
and wherein persistently storing the preparation log comprises: sending, by the master replicas of the at least two transaction participants, the preparation logs to the transaction status manager of the master node for the transaction status manager to write the preparation logs into a target transaction buffer; persistently storing, by the target transaction buffer, the preparation logs written by the at least two transaction participants in the corresponding master replicas; and synchronizing the preparation logs in batches to the at least one slave node to be persistently stored to the corresponding slave replicas (KR1017 – at step 810, the master replicator may receive (i.e. is sent) the requested operation for at least one of the master memory store 743 and the slave memory store that the slave storage device contains. At step 820, the master replicator stores the received operation in the master replication log (the replication log included in the master storage) and stores information about the location of the operation to be performed in the master replication log. Further, the master replication log can be transferred to the slave storage device. At this time, the slave replication log included in the slave storage device can be synchronized with the transferred master replication log. The master replicator may also perform reads and/or writes to the master replication logs by storing the operations received in step 820 in a buffer cache area (i.e. target transaction buffer) in the form of a memory mapping file [p.9 lines 8-38].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Lee, Lahiri, and KR1017 before them, to modify the system of Lee, Lahiri and KR1017 with the teachings of KR1017, as indicated above. One would have been motivated to make such a modification to ensure consistency between memory stores (KR1017 [Abstract]).
Claim 14 corresponds to claim 4 and is rejected accordingly.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Lahiri in view of CN115103011A (CN115103011A, Chen, 2022 (hereinafter “Xu”).
Regarding claim 5, Lee teaches:
in response to a pre-preparation request initiated by the transaction coordinator for the target transaction, return a log identifier of the preparation log corresponding to the target transaction for the log identifier to be added to a log identifier set comprised in the preparation request; and add the log identifier set to the preparation log in response to the preparation request (Lee – the commit protocol begins at 520, where the database client 502 sends a request to commit a transaction (i.e. target transaction) to the worker node 512 in a communication 522. The worker node 512 receives a request at 524 and sends the commit request to the coordinator node 506 in communication 526. The coordinator node 506 initiates the commit process at 528, and sends communications 530 to the worker nodes 512, 516 to prepare the worker nodes (i.e. transaction participant) for the transaction commit. The communications 530 include a transaction identifier for the transaction to be committed. The transaction identifier can be a transaction identifier associated with a connection between the worker node and the database client. In precommit blocks 532, each worker node 512, 516 executes SetAsPrepared to precommit the transaction, assigning the transaction the LCT (i.e.log identifier, see Table 1 [0070]) currently maintained at the worker node. The worker nodes 512, 516 then write the transaction to persistent storage, such as in a precommit log (i.e. preparation log), in block 534 [0093-0094].)
wherein the distributed system comprises a plurality of corresponding replicas for persistently storing the preparation log, wherein the plurality of replicas comprise a master replica and at least one slave replica (Lee –in precommit blocks 532, each worker node 512, 516 (i.e. each of the plurality of replicas) executes SetAsPrepared to precommit the transaction, assigning the transaction the LCT currently maintained at the worker node. The worker nodes 512, 516 (i.e. each of the plurality of replicas) then write the transaction to persistent storage, such as in a precommit log (i.e. preparation log), in block 534. The worker nodes 512, 516 then communicate with the coordinator node 502, via notifications 536, indicating that the transaction has been precommitted at the worker nodes and confirming to the coordinator about the commit readiness of the worker nodes [0094]. Examiner interprets that all the worker nodes (100%) must persistently store the preparation log and return a persistence result to the coordinator in order to confirm commit readiness to the coordinator.)
Lee modified by Lahiri does not appear to teach:
wherein when switching between the master replica and the slave replica is performed, and a status of the target transaction on a new master replica is unknown, the new master replica acquires, from the preparation log, a log identifier corresponding to another transaction participant other than a transaction participant that the new master replica belongs to, and queries, based on the acquired log identifier, a preparation log persistently stored by the another transaction participant for the target transaction; wherein the new master replica indicates the transaction coordinator that persistently storing corresponding preparation logs are successfully performed when all other transaction participants persistently store the preparation logs
However, Xu teaches:
wherein when switching between the master replica and the slave replica is performed, and a status of the target transaction on a new master replica is unknown, the new master replica acquires, from the preparation log, a log identifier corresponding to another transaction participant other than a transaction participant that the new master replica belongs to, and queries, based on the acquired log identifier, a preparation log persistently stored by the another transaction participant for the target transaction; wherein the new master replica indicates the transaction coordinator that persistently storing corresponding preparation logs are successfully performed when all other transaction participants persistently store the preparation logs (Xu – if the data node in the other data center is not available, then preferentially switching the main copy of the data node in the other data center. The processing process corresponding to the plurality of unusable condition is described, in the process, it relates to the switching of the master-slave generally speaking, each slave copy is synchronous with the data of the main copy, then when the main copy is not used for switching, especially need to pay attention to the data consistency between the remaining copies, can be selected as a new master copy from the copy and the data fragment other from the log synchronization, if there is a log of the main copy of the non-available machine, it can according to the log in the new main recovery data, so that the log synchronization result is more reliable [Xu, p. 10 lines 15-24].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Lee, Lahiri, and Xu before them, to modify the system of Lee and Lahiri with the teachings of Xu as indicated above. One would have been motivated to make such a modification to improve availability of the system and ensure performance and consistency (Xu [p.2 lines 16-20]).
Claim 15 corresponds to claim 5 and is rejected accordingly.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Lahiri in view of Kemmler (EP 3076308 A1, hereinafter “Kemmler”).
Regarding claim 6, Lee modified by Lahiri and Xu does not appear to teach:
wherein the new master replica and a replica of the another transaction participant are located on a same node in the distributed system; and the querying, based on the log identifier, a preparation log comprises: querying, by the new master replica, whether transaction status information of the target transaction is cached in a memory of the node on which the new master replica is located; and in response to the querying being successful, restoring, by the new master replica based on the transaction status information, a transaction status of the target transaction in a transaction sequence maintained by the new master replica; or in response to that the querying being unsuccessful, querying, by the new master replica based on the acquired log identifier on the node on which the new master replica is located, the preparation log persistently stored by the another transaction participant for the target transaction
However, Kemmler teaches:
wherein the new master replica and a replica of the another transaction participant are located on a same node in the distributed system; and the querying, based on the log identifier, a preparation log comprises: querying, by the new master replica, whether transaction status information of the target transaction is cached in a memory of the node on which the new master replica is located; and in response to the querying being successful, restoring, by the new master replica based on the transaction status information, a transaction status of the target transaction in a transaction sequence maintained by the new master replica; or in response to that the querying being unsuccessful, querying, by the new master replica based on the acquired log identifier on the node on which the new master replica is located, the preparation log persistently stored by the another transaction participant for the target transaction (Kemmler – as a database query may only be executed fully on replicate data elements or on original data elements the engines 122 may further be designed such that if they determine that a database query could have been executed on the slave telecommunication node, however cannot because the corresponding data elements are missing in the main memory (i.e. cached in memory) of the slave telecommunications node 104, the engines 122 create or access a log file 126 and create an entry in the log file indicating that some of the data elements 116 of the master telecommunication node 102 have to be replicated and stored in the main memory 120 of the slave telecommunications node 104 [0046].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Lee, Lahiri, Xu, and Kemmler before them, to modify the system of Lee, Lahiri, and Xu with the teachings of Kemmler, as indicated above. One would have been motivated to make such a modification to decrease data inconsistencies between master and slave data (Kemmler [0005]).
Claim 16 corresponds to claim 6 and is rejected accordingly.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Lahiri view of Fan (WO2019042174 A1, hereinafter “Fan”).
Regarding claim 9, Lee teaches:
wherein the demarcation location is recorded in the preparation log during generation of the preparation log (Lee – in precommit blocks 532, each worker node 512 executes SetAsPrepared to precommit the transaction, assigning the transaction the LCT currently maintained at the worker node. The worker nodes 512, 516 then write the transaction to persistent storage, such as in a precommit log (i.e. preparation log) in block 534 [0094]. LCT is the transaction commit timestamp, or CTS, at the worker node (see Table 1 [0070]. Examiner interprets that CTS is what is eventually written to the commit log (i.e. demarcation location).)
Lee modified by Lahiri does not appear to teach:
and wherein the demarcation location is in the predetermined recording log when frequency of performing a transaction operation is less than predetermined frequency
However, Fan teaches:
and wherein the demarcation location is in the predetermined recording log when frequency of performing a transaction operation is less than predetermined frequency (Fan – a primary database acquiring, in response to a transaction commit request, the log difference between transaction logs of the primary database and transaction logs which have been synchronized to the standby database; if the log difference is greater than a first threshold, suspending a transaction commit operation; and if the log difference is less than or equal to the first threshold, executing the transaction commit operation (Abstract).)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Lee, Lahiri, and Fan before them, to modify the system of Lee and Lahiri with the teachings of Fan as indicated above. One would have been motivated to make such a modification to prevent data from being lost and ensuring a timely response of the database (Fan [p.2 lines 23-26]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Lahiri in view of Lahiri in view of Little (Pub. No. US 2015/0248308 A1, hereinafter “Little”).
Regarding claim 10, Lee modified by Lahiri does not appear to teach:
in response to determining that an abnormality occurs on the transaction coordinator and is recovered, resend the persistence results to the transaction coordinator for the recovered transaction coordinator to initiate a corresponding transaction execution request to all transaction participants based on the persistence results that are resent by the transaction participants
However, Little teaches:
in response to determining that an abnormality occurs on the transaction coordinator and is recovered, resend the persistence results to the transaction coordinator for the recovered transaction coordinator to initiate a corresponding transaction execution request to all transaction participants based on the persistence results that are resent by the transaction participants (Little – in the event of a system failure or a failure of transaction manager 110 (e.g., a crash or power failure, i.e. abnormality occurs), the system may flush the transaction log and contents of semi-durable storage to durable storage by writing the transaction log to durable storage. Additionally, transaction participant may provide a participant log having rollback states, executed actions/processes of a distributed transaction, and other information enabling rollback or commitment of processes of a distributed transaction [0026-0027].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Lee, Lahiri, and Xu before them, to modify the system of Lee and Lahiri with the teachings of Little, as indicated above. One would have been motivated to make such a modification to survive system failure and improve write speed (Little [0001]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RANJIT P DORAISWAMY whose telephone number is (571)270-5759. The examiner can normally be reached Monday-Friday 9:00 AM - 5:00 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, Sanjiv Shah can be reached at (571) 272-4098. 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.
/RANJIT P DORAISWAMY/ Examiner, Art Unit 2166
/SANJIV SHAH/ Supervisory Patent Examiner, Art Unit 2166
Prosecution Insights