Office Action 1: Non-Final Rejection (2023-05-01)
Rejection types: 101 - Patent-Eligible Subject Matter, 103 - Obviousness, Double Patenting

CLAIMS:
CLAIMS

1\. A method for synchronization of node relational databases in a relational database system, said relational database system comprising a plurality of validation nodes each comprising a node relational database and, optionally, a client node, where one of the plurality of validation nodes is a primary validation node, the primary validation node having received a transaction message from another validation node or the client node, the transaction message comprising an instruction to modify the node relational databases, where each of the validation nodes stores, in its node relational database, a chain of data blocks, where each data block in the chain of data blocks comprises at least a cryptographically unambiguous identifier of a previous data block, each block further comprising one or more ordered transaction messages, the method comprising:
a) the primary validation node making a save point for a primary validation node
relational database of the primary node, the save point creating a state of the primary validation node relational database to which the primary validation node relational database can be reverted to, at a later point in time, so that the primary validation node can carry out the instruction in the transaction message and later roll back the primary validation node relational database to the state of the primary validation node relational database present before the save point;
b) the primary validation node attempting to carry out the instruction in the transaction message and, if the attempt to carry out the instruction is successful:
c) the primary validation node storing a data block in the primary validation node relational database, said data block comprising the at least one transaction message;
and d) the primary validation node creating a cryptographically unambiguous identifier (CUD) of the data in the block;
e) the primary validation node sending a block message to a non-primary validation node of the plurality of validation nodes, the block message comprising the
data block and the cryptographically unambiguous identifier of the data block;
f) the non-primary validation node receiving the block message, and creating a save point for a non-primary validation node relational database of the non-primary validation node, the save point creating a state of the non-primary validation node relational database to which the non-primary validation node relational database can be
reverted to at a later point in time so that the non-primary validation node tentatively can carry out the instruction in the transaction message and later roll back the non-primary validation node relational database to the state of the non-primary validation node relational database present before the save point; g) the non-primary validation node attempting to carry out the instruction in the transaction message in the block message so as to arrive at a non-primary validation node relational database that is the same as a state of the primary validation node relational database and, if successful, storing a data block in the non-primary validation node relational database, the data block comprising the at least one transaction message;
h) the non-primary validation node creating a cryptographically unambiguous identifier of the data in the data block; and
i) the primary and non-primary validation nodes removing their respective save
points based on a predetermined number of the plurality of validation nodes having achieved identical blocks, wherein a determination of whether the primary and non- primary validation nodes have achieved identical blocks comprises using a consensus algorithm.

2\. The method of claim 1 wherein the primary validation node making the save point for the primary validation node relational database comprises the primary validation node, after creating the save point, creating a nested save point that enables rollback of a transaction, and
releasing that the nested save point if the transaction is carried out successfully.

3\. The method of claim 1 wherein:
the non-primary validation node checks whether the cryptographically unambiguous identifier created in step h) corresponds to the cryptographically unambiguous identifier received in step f), and sends a commit message to the plurality of validation nodes wherein the commit message comprises at least one of:
i. a first type of commit message sent only when the non-primary validation node has carried out step h) but not i), and the conditions for sending the second type of commit message is not fulfilled; and
ii. a second type of commit message sent only when the validation node has received, from different validation nodes, a predetermined minimal
number P of commit messages of the first type; and
step i) comprises a validation node releasing its save point only when a predetermined number C of commit messages of the second type has been received from different validation nodes, and where C > P.

4\. The method of claim 3 where each of the validation nodes repeatedly, with a predetermined minimal time interval, sends out the commit messages of the first or second type to all other validation nodes, when conditions for sending such messages are fulfilled.

5\. The method of claim 3 wherein:
each of the plurality of validation nodes repeatedly, with a predetermined minimal time interval, sends out a third type of commit message to all other validation nodes of the plurality of validation nodes, the third type of commit message indicating that the validation node sending
the third type of commit message is in a state wherein conditions for sending either the first and/or the second type of commit messages are not fulfilled.

6\. The method according to claim 1 where the transaction messages are signed with a digital signature.

7\. The method according to claim 1 where the data on which the cryptographically unambiguous identifier depends, additionally comprises a timestamp, or information about block height.

8\. The method according to claim 1 where the cryptographically unambiguous identifier is a hash.

9\. The method according to claim 1 where the primary validation node ends the procedure and rolls back changes if a validation of the transaction message is faulty in the step b).

10\. The method according to claim 1 where the non-primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step g).

11\. The method according to claim 1, wherein said each of said node relational databases comprises:
a first table comprising database information records;
a second table comprising at least one transaction message that have modified at least one of said records; and
a third table comprising a plurality of cryptographically unambiguous identifiers (CUls), where each CUI is a CUI of a data block, wherein each data block comprises at least the CUI of an immediately previously stored data block and at least one data block comprises at least one transaction message from the second table.

12\. The method according to claim 11, wherein each CUI in the third table is logically linked to one or more of the transaction messages in the second table.

13\. A relational database system comprising a memory device, a processor operatively coupled with the processor, a plurality of validation nodes each comprising a node relational database, each node relational database being a replicated copy of one of the same relational database and, optionally a client node, where at least one of the plurality of validation nodes is capable of being a primary validation node, where the plurality of validation nodes are capable of exchanging a transaction message comprising an instruction to modify the node relational database, where each of the validation nodes stores, in its node relational database, a chain of data blocks, where each data block in the chain of data blocks comprises at least a cryptographically unambiguous identifier of a previous data block, wherein:
the primary validation node is operable to make a save point for a primary validation node relational database of the primary validation node, the save point creating a state of the primary validation node relational database to which the primary validation node relational database can be reverted to, at a later point in time, so that the primary validation node can carry out the instruction in the transaction message and later roll back the primary validation node relational database to the state of the primary validation node relational database present before the save point, the primary validation node is operable to attempt to carry out the instruction in the transaction message and, if the attempt is successful:
the primary validation node stores a data block in the primary validation
node relational database, said data block comprising the at least one transaction message;
the primary validation node creates a cryptographically unambiguous identifier (CUD) of the data in the block;
the primary validation node sends a block message to a non-primary
validation node of the plurality of validation nodes, the block message comprising the data block and the cryptographically unambiguous identifier of the data block;
the non-primary validation node is operable to receive the block message, and
creates a save point for a non-primary validation node relational database of the non-
primary validation node, the save point creating a state of the non-primary validation node relational database to which the non-primary validation node relational database can be reverted to at a later point in time so that the non-primary validation node tentatively can carry out the instruction in the transaction message and later roll back the non-primary validation node relational database to the state of the non-primary validation node relational database present before the save point;
the non-primary validation node is operable to attempt to carry out the instruction in the transaction message in the block message so as to arrive at a non-primary validation node relational database that is the same as a state of the primary validation node relational database and, if successful, storing a data block in the non-primary validation node relational database, the data block comprising the at least one transaction message;
the non-primary validation node is operable to create a cryptographically
unambiguous identifier of the data in the data block; and
the primary and non-primary validation nodes are operable to remove their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blocks, wherein a determination of whether the primary and non-primary validation nodes have achieved identical blocks comprises using a
consensus algorithm.

14\. The relational database system according to claim 13, wherein:
the non-primary validation node is operable to check whether the cryptographically unambiguous identifier created in step h) corresponds to the
cryptographically unambiguous identifier received in step f), and sends a commit message to the plurality of validation nodes wherein the commit message comprises at least one of:
i. a first type of commit message sent only when the non-primary validation node has carried out step h) but not i), and the conditions for
sending the second type of commit message is not fulfilled; and
ii. a second type of commit message sent only when the validation node has received, from different validation nodes, a predetermined minimal number P of commit messages of the first type; and
step i) comprises a validation node releasing its save point only when a
predetermined number C of commit messages of the second type has been received from different validation nodes, and where C > P.

15\. The relational database system according to claim 14, wherein:
each of the plurality of validation nodes are operable to repeatedly, with a predetermined
minimal time interval, send out a third type of commit message to all other validation nodes of the plurality of validation nodes, the third type of commit message indicating that the validation node sending the third type of commit message is in a state wherein conditions for sending either the first and/or the second type of commit messages are not fulfilled.
16\. A non-transitory computer readable memory storing software thereon that when executed by a computer performs a method for synchronization of node relational databases in a relational database system, said relational database system comprising a plurality of validation nodes each comprising a node relational database, and, optionally a client node, where one of the plurality of validation nodes is a primary validation node and where each of the nodes stores, in its node relational database, a chain of data blocks, where each data block in the chain of data blocks comprises at least a cryptographically unambiguous identifier of a previous data block, each block further comprising one or more ordered transaction messages;
the software being executed by processors of each of the nodes and to exchange transaction messages between the nodes, where each transaction message comprises an instruction to modify the records of the node relational databases, the software being adapted to, when executed by a node which is a primary validation node, when a transaction message has been received from a node;
the software being executed to make a save point for a primary validation node relational database of the primary validation node, the save point creating a state of the primary validation node relational database to which the primary validation node relational database can be reverted to, at a later point in time, so that the primary validation node can carry out said instruction in said transaction message and later to roll back the primary validation node relational database to the state of the primary validation node relational database present before the save point;
the software being executed to provide the transaction message to the node relational database for attempting to carry out the instruction in the transaction message and, if the attempt to carry out the instruction is successful, to compute a cryptographically unambiguous identifier
of a data block comprising 1) the least one transaction message and 2) a cryptographically unambiguous identifier of the immediately preceding data block of the block chain of the primary validation node, to store the data block in the primary validation node relational database and to provide the cryptographically unambiguous identifier to the node relational database for storage;
the software being executed to:
send a block message to at least one non-primary validation node, the block message comprising the data block and the cryptographically unambiguous identifier of the data block; and
the software being executed to receive commit messages from the at least one non-primary validation node, and, if at least a predetermined number
of commit messages has been received, to instruct the relational database to remove any save points for the records.

17\. The non-transitory computer readable memory according to claim 16 further comprising:
the software being executed to cause the non-primary validation node to check whether the cryptographically unambiguous identifier corresponds to the cryptographically unambiguous identifier received, and sends a commit message to the plurality of validation nodes wherein the commit message comprises at least one of: i. a first type of commit message sent only when the non-primary validation node has carried out creating a cryptographically unambiguous identifier of the data in the data block but not the primary and non-primary validation nodes removing their respective save points, and the conditions for sending the second type of commit message is not fulfilled, ii. a second type of commit message sent only when the validation node has received, from different validation nodes, a predetermined minimal number P of commit messages of the first type, wherein step i) comprises a validation node releasing its save point only when a predetermined number C of commit messages of the second type has been received from different validation nodes, and where C > P.

18\. The non-transitory computer readable memory according to claim 17 further comprising:
the software being executed to cause each of the plurality of validation nodes repeatedly, with a predetermined minimal time interval, sends out a third type of commit message to all other validation nodes of the plurality of validation nodes, the third type of commit message indicating that the validation node sending the third type of commit message is in a state wherein conditions for sending either the first and/or the second type of commit messages are not fulfilled.

19\. The non-transitory computer readable memory according to claim 16, wherein the software is run on a on a non-primary validation node, which is configured to:
receive a block message from a primary validation node;
provide the transaction message to the node relational database for execution, and if
execution is successful;
compute a cryptographically unambiguous identifier (CUI) of a data block, said data block comprising the at least one transaction message and the CUI of the immediately preceding block of the node; and
comparing the CUI received in the block message from the primary validation node
with the CUI computed by the node, and, if the CUls are the same, to send a commit message to at least one validation node. 5504964.1 5 10 15 20 25 30 35

OFFICE ACTION:
Notice of Pre-AIA  or AIA  Status
The present application 17/719,933, filed on 4/13/2022 (or after March 16, 2013), is being examined under the first inventor to file provisions of the AIA  (First Inventor to File).
In the event the determination of the status of the application as subject to AIA  35 U.S.C. 102 and 103 (or as subject to pre-AIA  35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application is a CON of US Application # 16/628,563 filed on 01/03/2020 is now US PAT 11334678, US Application # 16/628,563 is a 371 of PCT/EP2018/068421 filed on 07/06/2018
DETAILED ACTION
Claims 1-19 are pending in this application
Drawings
The Drawings filed on 4/29/2022 are acceptable for examination purpose
Priority
Acknowledgment is made of applicant’s claim for Swedish Patent Application foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy of Swedish Patent application # 1750892-0  (7/6/2017) has been filed on 13/2020.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 4/13/2022 is in
compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure
statement is being considered by the examiner
Statutory Review under 35 USC § 101
Claims 1-12 are directed towards a method and have been reviewed.
Claims 1-12 perform the method steps, determined to be directed to significantly more than an abstract idea based on currently known judicial exceptions.
Claims 13-15 are directed toward a system and have been reviewed.
Claim 13-15 appear to be statutory, as the system includes hardware (at least one data processor) as disclosed in ¶ page 7, line 6-18, fig 2 of the applicant’s specification referring to physical processor cores.
Claims 16-19 are directed to a non-transitory computer readable memory storing software thereon that when executed by a computer performs a method for synchronization of node relational database in a relational database system, said relational database system comprising a plurality of validation nodes each comprising a node relational database, and have been reviewed.
Claims 16-19 appear to be statutory, as the claim says non-transitory.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The judicial exception is not integrated into a practical application.
At Step 1:
The claim is directed to a method and thus directed to a statutory category
At Step 2A, Prong One:
The claim recites the following limitations directed to an abstract idea:
“a) the primary validation node making a save point for a primary validation node relational database of the primary node…………………….. ………transaction message and later roll back the primary validation node relational database to the state of the primary validation node relational database present before the save point”, ”, which recites a mental process as an evaluation or judgement of transaction message, rollback , validation of data.  Consistent with the specification as at [page 2-3] one can mentally to validate, roll back transaction
“b) the primary validation node attempting to carry out the instruction in the transaction message and, if the attempt to carry out the instruction is successful”, which recites a mental process of transaction message or judgement of the transaction message.  Consistent with the specification as at [page 2-3] one can mentally to validate, roll back transaction save point
“c) the primary validation node storing a data block in the primary validation node relational database, said data block comprising the at least one transaction message; which recites a mental process as an evaluation or judgement of transaction message, validation node, unambiguous identifier of the data in the block.  Consistent with the specification as at [page 2-4] one can mentally to transaction message, validation node, unambiguous identifier of the data in the block
and
d) the primary validation node creating a cryptographically unambiguous identifier (CUD) of the data in the block”, which recites a mental process as an evaluation or judgement of transaction message, validation node, unambiguous identifier of the data in the block.  Consistent with the specification as at [page 2-4] one can mentally to transaction message, validation node, unambiguous identifier of the data in the block
“e) the primary validation node sending a block message to a non-primary validation node of the plurality of validation nodes, the block message comprising the
data block and the cryptographically unambiguous identifier of the data block”, which recites a mental process as an evaluation or judgement of block message, validation node;
f) the non-primary validation node receiving the block message, and creating a save point for a non-primary validation node relational database of the non-primary validation node, the save point creating a state of the non-primary validation node relational database to which the non-primary validation node relational database can be
reverted to at a later point in time so that the non-primary validation node tentatively can carry out the instruction in the transaction message and later roll back the non-primary validation node relational database to the state of the non-primary validation node relational database present before the save point”, which recites a mental process as an evaluation or judgement of transaction message, validation node, roll back, save point.  Consistent with the specification as at [page 3-5] one can mentally to transaction message, validation node, unambiguous identifier of the data in the block;
g) the non-primary validation node attempting to carry out the instruction in the transaction message in the block message so as to arrive at a non-primary validation node relational database that is the same as a state of the primary validation node relational database and, if successful, storing a data block in the non-primary validation node relational database, the data block comprising the at least one transaction message, which recites a mental process as an evaluation or judgement of block message, validation node, data block, non-primary validation node.  Consistent with the specification as at [page 3-6] one can mentally to access block message, validation node, data block, non-primary validation node;
“h) the non-primary validation node creating a cryptographically unambiguous identifier of the data in the data block; and i) the primary and non-primary validation nodes removing their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blocks, wherein a determination of whether the primary and non- primary validation nodes have achieved identical blocks comprises using a consensus algorithm”, which recites a mental process as an evaluation or judgement of removing save point, validation node, data block, non-primary validation node.  Consistent with the specification as at [page 3-8] one can mentally to execute routines such as algorithm in performing removing save point, validation node, data block, non-primary validation node
At Step 2A, Prong Two:
The claim recites the following additional elements:
That the method is computer-implemented and operations are performed by one or more computer processors which is a high-level recitation of a generic computer components and represents mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
“a) the primary validation node making a save point for a primary validation node relational database of the primary node…………………….. ………transaction message and later roll back the primary validation node relational database to the state of the primary validation node relational database present before the save point”, recites insignificant extra-solution activity as validation of node (i.e. mere data gathering) such as “roll back information” as identified in MPEP 2106.05(g) and does not provide integration into a practical application.
“b) the primary validation node attempting to carry out the instruction in the transaction message and, if the attempt to carry out the instruction is successful”, which recites a mental process of transaction message or judgement of the transaction message.  as identified in MPEP 2106.05(g) and does not provide integration into a practical application
“c) the primary validation node storing a data block in the primary validation node relational database, said data block comprising the at least one transaction message, recites insignificant extra-solution activity as validation of node (i.e. mere data gathering) such as “transaction message” as identified in MPEP 2106.05(g) and does not provide integration into a practical application
d) the primary validation node creating a cryptographically unambiguous identifier (CUD) of the data in the block”, recites insignificant extra-solution activity as validation of node (i.e. mere data gathering) such as “data block” as identified in MPEP 2106.05(g) and does not provide integration into a practical application
“e) the primary validation node sending a block message to a non-primary validation node of the plurality of validation nodes, the block message comprising the
data block and the cryptographically unambiguous identifier of the data block”, recites insignificant extra-solution activity as validation of node (i.e. mere data gathering) such as “data block” as identified in MPEP 2106.05(g) and does not provide integration into a practical application
f) the non-primary validation node receiving the block message, and creating a save point for a non-primary validation node relational database of the non-primary validation node, the save point creating a state of the non-primary validation node relational database to which the non-primary validation node relational database can be
reverted to at a later point in time so that the non-primary validation node tentatively can carry out the instruction in the transaction message and later roll back the non-primary validation node relational database to the state of the non-primary validation node relational database present before the save point”, recites insignificant extra-solution activity as validation of node (i.e. mere data gathering) such as “data block”, “transaction message”, “roll back” as identified in MPEP 2106.05(g) and does not provide integration into a practical application
g) the non-primary validation node attempting to carry out the instruction in the transaction message in the block message so as to arrive at a non-primary validation node relational database that is the same as a state of the primary validation node relational database and, if successful, storing a data block in the non-primary validation node relational database, the data block comprising the at least one transaction message, recites insignificant extra-solution activity as validation of node (i.e. mere data gathering) such as “data block”, “transaction message”, “roll back” as identified in MPEP 2106.05(g) and does not provide integration into a practical application;
“h) the non-primary validation node creating a cryptographically unambiguous identifier of the data in the data block; and i) the primary and non-primary validation nodes removing their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blocks, wherein a determination of whether the primary and non- primary validation nodes have achieved identical blocks comprises using a consensus algorithm”, recites insignificant extra-solution activity as validation of node (i.e. mere data gathering) such as “data block”, “achieved identical blocks”, “consensus algorithm” as identified in MPEP 2106.05(g) and does not provide integration into a practical application
At Step 2B:
The conclusions for the mere implementation using a computer are carried over and does not provide significantly more.
With respect to “a) the primary validation node making a save point for a primary validation node relational database of the primary node…………………….. ………transaction message and later roll back the primary validation node relational database to the state of the primary validation node relational database present before the save point”, identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.04(d)(II) iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; or v. Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014).
With respect to “d) the primary validation node creating a cryptographically unambiguous identifier (CUD) of the data in the block”, identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.04(d)(II) iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; or v. Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014).
With respect to “d) the primary validation node creating a cryptographically unambiguous identifier (CUD) of the data in the block”, identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.04(d)(II) iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; or v. Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014).
With respect to “c) the primary validation node storing a data block in the primary validation node relational database, said data block comprising the at least one transaction message, recites insignificant extra-solution activity as validation of node (i.e. mere data gathering) such as “transaction message”, identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.04(d)(II) iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; or v. Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014).
With respect to “e) the primary validation node sending a block message to a non-primary validation node of the plurality of validation nodes, the block message comprising the data block and the cryptographically unambiguous identifier of the data block”, identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.04(d)(II) iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; or v. Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014).
With respect to f) the non-primary validation node receiving the block message, and creating a save point for a non-primary validation node relational database of the non-primary validation node, the save point creating a state of the non-primary validation node relational database to which the non-primary validation node relational database can be reverted to at a later point in time so that the non-primary validation node tentatively can carry out the instruction in the transaction message and later roll back the non-primary validation node relational database to the state of the non-primary validation node relational database present before the save point”, identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.04(d)(II) iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; or v. Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014).
With respect to g) the non-primary validation node attempting to carry out the instruction in the transaction message in the block message so as to arrive at a non-primary validation node relational database that is the same as a state of the primary validation node relational database and, if successful, storing a data block in the non-primary validation node relational database, the data block comprising the at least one transaction message, identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.04(d)(II) iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; or v. Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014).
With respect to “h) the non-primary validation node creating a cryptographically unambiguous identifier of the data in the data block; and i) the primary and non-primary validation nodes removing their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blocks, wherein a determination of whether the primary and non- primary validation nodes have achieved identical blocks comprises using a consensus algorithm”,  identified as insignificant extra-solution activity above this is also WURC as court-identified see MPEP 2106.04(d)(II) iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; or v. Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014).
Looking at the claim 1 as a whole does not change this conclusion and the    claim 1 is ineligible, while treated as additional elements in the claim 1 rejection above primary validation node, transaction message, roll back, save point, data in the block, validation node storing a data block, identical blocks, consensus algorithm step might also  performed mentally as there is no indication where the part of the data block, transaction message manipulation validation nodes (i.e. it could be a mentally held data block manipulation) and there is no indication of whether the stop criteria is retrieved from recited in the claim.
Examiner applies above rejection of claim 1 to claims 13,16
Claims 2 further elaborates on the “wherein the primary validation node making the save point for the primary validation node relational database comprises the primary validation node, after creating the save point, creating a nested save point that enables rollback of a transaction, and releasing that the nested save point if the transaction is carried out successfully”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claims 3,14,17 further elaborates on the “the non-primary validation node checks whether the cryptographically unambiguous identifier created in step h) corresponds to the cryptographically unambiguous identifier received in step f), and sends a commit message to the plurality of validation nodes wherein the commit message comprises at least one of:
i. a first type of commit message sent only when the non-primary validation node has carried out step h) but not i), and the conditions for sending the second type of commit message is not fulfilled; and
ii. a second type of commit message sent only when the validation node has received, from different validation nodes, a predetermined minimal number P of commit messages of the first type; and
step i) comprises a validation node releasing its save point only when a predetermined number C of commit messages of the second type has been received from different validation nodes, and where C > P”,  which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claims 4,15, further elaborates on the “where each of the validation nodes repeatedly, with a predetermined minimal time interval, sends out the commit messages of the first or second type to all other validation nodes, when conditions for sending such messages are fulfilled”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claims 5,18, further elaborates on the “wherein: each of the plurality of validation nodes repeatedly, with a predetermined minimal time interval, sends out a third type of commit message to all other validation nodes of the plurality of validation nodes, the third type of commit message indicating that the validation node sending  the third type of commit message is in a state wherein conditions for sending either the first and/or the second type of commit messages are not fulfilled”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 6, further elaborates on the “where the transaction messages are signed with a digital signature”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 7, further elaborates on the “where the data on which the cryptographically unambiguous identifier depends, additionally comprises a timestamp, or information about block height”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 8, further elaborates on the “where the cryptographically unambiguous identifier is a hash”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 9, further elaborates on the “where the primary validation node ends the procedure and rolls back changes if a validation of the transaction message is faulty in the step  b)”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 10, further elaborates on the “where the non-primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step g)”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 11, further elaborates on the “wherein said each of said node relational relational database comprises: a first table comprising database information records; a second table comprising at least one transaction message that have modified at least one of said records; and  a third table comprising a plurality of cryptographically unambiguous identifiers (CUIs), where each CUI is a CUI of a data block, wherein each data block comprises at least the CUI of an immediately previously stored data block and at least one data block comprises at least one transaction message from the second table”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 12, further elaborates on the “wherein each CUI in the third table is logically linked to one or more of the transaction messages in the second table”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claim 19, further elaborates on the “receive a block message from a primary validation node;
provide the transaction message to the node relational database for execution, and if execution is successful:
compute a cryptographically unambiguous identifier (CUI) of a data block, said data block comprising the at least one transaction message and the CUI of the immediately preceding block of the node; and
comparing the CUI received in the block message from the primary validation node with the CUI computed by the node, and, if the CUls are the same, to send a commit message to at least one validation node”, which have been determined to be extra-solution activity that does not impose any meaningful limits on practicing the abstract idea.  See MPEP 2106.05(b)(I).   Even in combination, the additional details recited in these claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used.  Please visit http://www.uspto.gov/forms/.  The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-19 of US Application No. 17/719,933 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-12 of U.S. Patent No. 11,334,678. Although the claims at issue are not identical, they are not patentably distinct from each other because the patented claims perform the same steps as the claims in the instant application.
Instant US application: 17/719,933
US Patent No. 11,334,678
Claim 1,13,19, A method for synchronization of node relational relational database in a relational  database system, said relational database system comprising a plurality of validation nodes each comprising a node relational database and, optionally, a client node, where one of the plurality of validation nodes is a primary validation node, the primary validation node having received a transaction message from another validation node or the client node, the transaction message comprising an instruction to modify the node relational relational database, where each of the validation nodes stores, in its node relational database, a chain of data blocks, where each data block in the chain of data blocks comprises at least a cryptographically unambiguous identifier of a previous data block, each block further comprising one or more ordered transaction messages, the method comprising:
a) the primary validation node making a save point for a primary validation node relational database of the primary node, the save point creating a state of the primary validation node relational database to which the primary validation node relational database can be reverted to, at a later point in time, so that the primary validation node can carry out the instruction in the transaction message and later roll back the primary validation node relational database to the state of the primary validation node relational database present before the save point;
b) the primary validation node attempting to carry out the instruction in the transaction message and, if the attempt to carry out the instruction is successful:
c) the primary validation node storing a data block in the primary validation node relational database, said data block comprising the at least one transaction message;
and
d) the primary validation node creating a cryptographically unambiguous identifier (CUD) of the data in the block;
e) the primary validation node sending a block message to a non-primary validation node of the plurality of validation nodes, the block message comprising the data block and the cryptographically unambiguous identifier of the data block;
f) the non-primary validation node receiving the block message, and creating a save point for a non-primary validation node relational database of the non-primary validation node, the save point creating a state of the non-primary validation node relational database to which the non-primary validation node relational database can be reverted to at a later point in time so that the non-primary validation node tentatively can carry out the instruction in the transaction message and later roll back the non-primary validation node relational database to the state of the non-primary validation node relational database present before the save point;
g) the non-primary validation node attempting to carry out the instruction in the transaction message in the block message so as to arrive at a non-primary validation node relational database that is the same as a state of the primary validation node relational database and, if successful, storing a data block in the non-primary validation node relational database, the data block comprising the at least one transaction message;
h) the non-primary validation node creating a cryptographically unambiguous identifier of the data in the data block; and
i) the primary and non-primary validation nodes removing their respective save  points based on a predetermined number of the plurality of validation nodes having achieved identical blocks, wherein a determination of whether the primary and non- primary validation nodes have achieved identical blocks comprises using a consensus algorithm.
2. The method of claim 1 wherein the primary validation node making the save point for the primary validation node relational database comprises the primary validation node, after creating the save point, creating a nested save point that enables rollback of a transaction, and releasing that the nested save point if the transaction is carried out successfully
4. The method of claim 3 where each of the validation nodes repeatedly, with a predetermined minimal time interval, sends out the commit messages of the first or second type to all other validation nodes, when conditions for sending such messages are fulfilled.
6. The method according to claim 1 where the transaction messages are signed with a digital signature
7.  where the data on which the cryptographically unambiguous identifier depends, additionally comprises a timestamp, or information about block height,
8. The method according to claim 1 where the cryptographically unambiguous identifier is a hash.
10. The method according to claim 1 where the non-primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step g).
Claim 1, 11, A method for synchronization of node relational relational database in a relational database system, said relational database system comprising a plurality of validation nodes each comprising a node relational database and, optionally, client node, where one of the plurality of validation nodes is a primary validation node, the primary validation node having received at a transaction message from another validation node or the client node, the transaction message comprising an instruction to modify the node relational relational database, where each of the validation nodes stores, in its node relational database, a chain of data blocks, where each data block in the chain of data blocks comprises at least a cryptographically unambiguous identifier of a previous data block, each block further comprising one or more ordered transaction messages, the method comprising:
a) the primary validation node making a save point for a primary validation node relational database of the primary validation node, the save point creating a state of the primary validation node relational database to which the primary validation node relational database can be reverted to, at a later point in time, so that the primary validation node can carry out the instruction in the transaction message and later roll back the primary validation node relational database to the state of the primary validation node relational database present before the save point,
b) the primary validation node attempting to carry out the instruction in the transaction message and, if the attempt to carry out the instruction is successful:
c) the primary validation node storing a data block in the primary validation node relational database, said data block comprising the at least one transaction message,
d) the primary validation node creating a cryptographically unambiguous identifier (CUD) of the data in the block,
e) the primary validation node sending a block message to a non-primary validation node of the plurality of validation nodes, the block message comprising the data block and the cryptographically unambiguous identifier of the data block,
f) the non-primary validation node receiving the block message, and creating a save point for a non-primary validation node relational database of the non-primary validation node, the save point creating a state of the non-primary validation node relational database to which the non-primary validation node relational database can be reverted to at a later point in time so that the non-primary validation node tentatively can carry out the instruction in the transaction message and later roll back the non-primary validation node relational database to the state of the non-primary validation node relational database present before the save point,
g) the non-primary validation node attempting to carry out the instruction in the transaction message in the block message so as to arrive at a non-primary validation node relational database that is the same as a state of the primary validation node relational database and, if successful, storing a data block in the non-primary validation node relational database, the data block comprising the at least one transaction message,
h) the non-primary validation node creating a cryptographically unambiguous identifier of the data in the data block,
i) the primary and non-primary validation nodes removing their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blocks, wherein a determination of whether the primary and non-primary validation nodes have achieved identical blocks comprises using a consensus algorithm,
wherein the non-primary validation node checks whether the cryptographically unambiguous identifier created in step h) corresponds to the cryptographically unambiguous identifier received in step f), and sends a commit message to the plurality of validation nodes wherein the commit message comprises at least one of:
i. a first type of commit message sent only when the non-primary validation node has carried out step h) but not i), and the conditions for sending the second type of commit message is not fulfilled,
ii. a second type of commit message sent only when the validation node has received, from different validation nodes, a predetermined minimal number P of commit messages of the first type,
wherein step i) comprises a validation node releasing its save point only when a predetermined number C of commit messages of the second type has been received from different validation nodes, and where C>P,
wherein each of the plurality of validation nodes repeatedly, with a predetermined minimal time interval, sends out a third type of commit message to all other validation nodes of the plurality of validation nodes, the third type of commit message indicating that the validation node sending the third type of commit message is in a state wherein conditions for sending either the first and/or the second type of commit messages are not fulfilled.
2. The method of claim 1 wherein the primary validation node making the save point for the primary validation node relational database comprises the primary validation node, after creating the save point, creating a nested save point that enables rollback of a transaction, and releasing that the nested save point if the transaction is carried out successfully.
3. The method of claim 1 where each of the validation nodes repeatedly, with a predetermined minimal time interval, sends out the commit messages of the first or second type to all other validation nodes, when conditions for sending such messages are fulfilled
4. The method according to claim 1 where the transaction messages are signed with a digital signature.
5.  where the data on which the cryptographically unambiguous identifier depends, additionally comprises a timestamp, or information about block height,
6. The method according to claim 1 where the cryptographically unambiguous identifier is a hash.
8. The method according to claim 1 where the non-primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step g).
It would have been obvious to a person of ordinary skill was made to modify and/or to omit the additional elements of claim 1-12 of U.S. Patent No. 11,334,678 to arrive at the claims 1-19 of the instant application 17/719,933 because the ordinary skilled person would have realized that the remaining element(s) would perform the same function as before as shown above underlined limitations while  claim 1 of U.S. Patent No. 11,334,678,  wherein the non-primary validation node checks whether the cryptographically unambiguous identifier created in step h) corresponds to the cryptographically unambiguous identifier received in step f), and sends a commit message to the plurality of validation nodes wherein the commit message comprises at least one of:
i. a first type of commit message sent only when the non-primary validation node has carried out step h) but not i), and the conditions for sending the second type of commit message is not fulfilled,
ii. a second type of commit message sent only when the validation node has received, from different validation nodes, a predetermined minimal number P of commit messages of the first type,
wherein step i) comprises a validation node releasing its save point only when a predetermined number C of commit messages of the second type has been received from different validation nodes, and where C>P,
wherein each of the plurality of validation nodes repeatedly, with a predetermined minimal time interval, sends out a third type of commit message to all other validation nodes of the plurality of validation nodes, the third type of commit message indicating that the validation node sending the third type of commit message is in a state wherein conditions for sending either the first and/or the second type of commit messages are not fulfilled,  is absent of the limitation from instant application 17/719,933 claim 1, 13,16.  Omission and/or addition of elements and its function in combination is obvious expedient if the remaining elements perform same functions as before, as such instant application 17/719,933 claim 1, 13,16 are broader.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
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-19  is/are rejected under 35 U.S.C. 103 as being unpatentable over Salami et al., (hereafter Salami), US Pub.No. 2017/0345011 filed on May,2016, Douros et al., (hereafter Douros), US Pub.No. 2017/0011085 based on provisional application filed on Jul,2015 in view of Gray, US Pub.No. 2017/0353309 based on provisional application filed on Jun,2016
As to claim 1, 13,16  Salami teaches a system which including “A method for synchronization of node relational database in a database system, said database system comprising a plurality of validation nodes each comprising a node database” (0028, line 1-4, 0048, line 19-21,  0052, 0090, fig 1A-1B – Salami teaches blockchain nodes and synchronized across nodes and each blockchain node corresponds to database because each respective blockchain node in a database such as the state database as detailed in 0048, line 19-21, it is also noted that Salami teaches blockchain node receives and validates the transaction particularly transaction signature assigned public key, thus validation blockchain nodes of respective database maintains validated transactions)  and, optionally one or more client nodes (fig 1A-1B – Salami teaches multiple blockchain nodes connected in a client-server or peer-to-peer or distributed network environment)
“where one of the validation nodes is a primary validation node” (fig 1, 0097 – Salami teaches multiple blockchain nodes in a distributed computing environment, validating blockchain node or set of validating blockchain nodes, while each blockchain node acts as primary validation node due to respective transaction received and independently computes new state as detailed in 0097),
the primary validation node having received at least one transaction message from another validation node or a client, the transaction message comprising instructions to modify the node relational database, where each of the nodes stores, in its node database, a chain of data blocks, where each data block in the block chain     (fig 1, 0028, line 1-4, 0048 – Salami teaches blockchain nodes connected in a distributed computing network environment, and each blockchain node in a database  for example state of the database with respect to validation and transaction because transactions within the that block to the state of the database is applied , further each transaction associated with the respective message indicating the status of the transaction and/or update on to the node database state) comprises at least a cryptographically unambiguous identifier of the previous data block (0043,0048, line 19-23, page 8, 0049 – Salami teaches blockchain data structure including block header, this block header containing date, time block, reference to the previous block, “hash” block” particularly defining SHA-256 cryptographic algorithm, typically SHA-256 function applied to produce hash value, Salami’s SHA-256 cryptographic algorithm generates cryptographic identifier for blockchain node corresponds to corresponds to instant specification page 10 line 3 cryptographic unambiguous identifier), the method comprising the steps of, in order:
“a) the primary validation node making a save point for the primary validation node database” (Salami: 0038 – Salami teaches blockchain node that receives and validates the transaction corresponds to primary node validation particularly transaction signature associated with the message), “the save point creating a state of the primary validation node database to which the primary validation node database can be reverted to, at a later point in time” (Salami: page 6, 0037 line 1-2, page 7, para 0037, line 1-6, line -0039 – Salami teaches blockchain node database determines not only validating transaction, public key signature of the respective message and as such each blockchain node and the initial state containing the time and date corresponds to save point because each transaction validation message maintains timestamp)
“b) the primary validation node attempting to carry out the instructions in the at least one transaction message and, if attempt is successful” (0069, 0071 – Salami teaches each transaction validation  and the message, particularly process the transaction send and/or receive associated with the message thereby it indicates transaction successful)
“c) the primary validation node storing a data block in the node database, said data block comprising the at least one transaction message” (0039,0048 – Salami teaches blockchain nodes database arranged in tree node structure and each primary node validation with respect to the node state database)  and
“d) the primary validation node creating a cryptographically unambiguous identifier of the data in the block” (0043, 0048 – Salami teaches SHA-256 cryptographic algorithm is identical to instant specification page 4, line 14),
“e) the primary validation node sending a block message to the at least one non-primary validation node, the block message comprising the data block and the cryptographically unambiguous identifier of the data block” (0043,0048, line 19-23,  page 8, 0049 – Salami teaches blockchain data structure including block header, this block header containing date, time block, reference to the previous block, “hash” block” particularly defining SHA-256 cryptographic algorithm, typically SHA-256 function applied to produce hash value, Salami’s SHA-256 cryptographic algorithm generates cryptographic identifier for blockchain node corresponds to corresponds to instant specification page 4, line 14, page 10 line 3 cryptographic unambiguous identifier),
“f) creating a save point for the node database” (Salami: page 6, 0037 line 1-2, page 7, para 0037, line 1-6, line -0039 – Salami teaches blockchain node database determines not only validating transaction, public key signature of the respective message and as such each blockchain node and the initial state containing the time and date corresponds to save point because each transaction validation message maintains timestamp),
“g) primary validation node attempting to carry out the instruction in the transaction message in the block message and, if 2successful” (0039,0048 – Salami teaches blockchain nodes database arranged in tree node structure and each primary node validation with respect to the node state database); “storing a data block in the node database, the data block comprising the at least one transaction message” (0097 – Salami teaches blockchain nodes, transactions associated with the messages and their state stored in the temporary working memory known as “mempool” until a new, valid block that includes the transaction is received),
“h) the at least one non-primary validation node creating a cryptographically unambiguous identifier of the data in the data block” 0043,0048, line 19-23,  page 8, 0049 – Salami teaches blockchain data structure including block header, this block header containing date, time block, reference to the previous block, “hash” block” particularly defining SHA-256 cryptographic algorithm, typically SHA-256 function applied to produce hash value, Salami’s SHA-256 cryptographic algorithm generates cryptographic identifier for blockchain node corresponds to corresponds to instant specification page 4, line 14, page 10 line 3 cryptographic unambiguous identifier),
“i) the validation nodes removing their save points if a predetermined number of validation nodes has achieved identical blocks” (Salami: 0102, 0104 – Salami teaches blockchain nodes validation process particularly with respect to update function, further Salami teaches synchronization, validation of data across blockchain nodes, thereby eliminating other blockchain node(s) in a distributed computing environment)
It is however, noted that Salami does not disclose “f) the at least one non-primary validation node receiving the block message, the at least one non-primary validation node attempting to carry out the instruction in the transaction message”.  On the other hand, Douros disclosed f) the at least one non-primary validation node receiving the block message,  the at least one non-primary validation node attempting to carry out the instruction in the transaction message” (Douros: 0107, 0139-0140, fig 16 – Douros teaches distributed database nodes and transactions particularly each transaction message generates commit identifier determines whether any conflicts and/or safe commits, during determination process identifies transaction state such as abort, suspend and preparing state, further, Douros also teaches examining time intervals for each transaction of both primary validation and non-primary validation with respect to time for validation phrase that including messages/phases associated with the transaction as detailed in 0107).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine concurrent transaction particularly transactions includes determining time of imitation maintain plurality of nodes, records of transactions in a distributed database system of  Douros et al., with blockchain nodes configured in a distributed computing environment of Salami because that would have allowed users of Salami to identify list of transactions of each node, transaction state and sending and receiving messages from the each node, while performing validation phase to identify priority and non-priority nodes ,ie., designating “priority or leader” node that is responsible for assigning transaction identifiers to new transactions (Douros: 0103), further delaying non-priority transaction allows improving optimized distributed database operations including both read and write transactions, thus transaction manager may resolve conflict resolution between concurrent transaction while maintain atomicity of transactions (Douros: 0049-0050)
It is however, noted that Salami, Douros do not disclose “where the determination if the validation nodes have achieved identical blocks is done using a consensus algorithm, although Salami teaches validation blockchain database nodes(Salami: fig 1-2, fig 7, element 106,108,110,112); prior art of Douros teaches time intervals associated with the transactions and validation phrase (Douros: 0107).          On the other hand, Gray disclosed “where the determination if the validation nodes   have achieved identical blocks is done using a consensus algorithm” (0007, 0052-0054 – Gary teaches cryptlet to execute on blockchain database node first validating the transaction, perform actions in a enterprise network environment, ie., each node employs consensus algorithm to decide on which transactions to keep and discard, while each node in the blockchain ensures integrity and authenticity as detailed in 0007.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine cryptographic applications in blockchain system of Gray into users of Salami,Dourous because that would have allowed users of Salami,Dourous to define smart contract associated with a blockchain particularly cryptlet of Gary to perform required transactions, while validating the message associated with the transactions (Gary: 0009), it is noted that Gray’s cryptlet provides response to the cryptodelegate and blockchain (Gary:0019, line 23-25), thus improves secure and authentic transaction in a distributed computing environment (Gray: 0025)
As to claim 2, Dourous  disclosed  “wherein the primary validation node making the save point for the primary validation node relational database comprises the primary validation node, after creating the save point, creating a nested save point that enables rollback of a transaction, and releasing that the nested save point if the transaction is carried out successfully” ( Dourous: 0161-0163, fig 29 – Dourous teaches transaction manager of nodes identifying and completing transaction writing  i.e., prepare state at the participating nodes, validating and sending message of the identified transactions, further if any transaction cannot be committed, Dourous’s algorithm finally, identifies particular node transaction’s changes are rolled back)
As to claim 3, 14,17, Salami disclosed the cryptographically unambiguous identifier received in step f), (0043,0048, line 19-23, page 8, 0049 – Salami teaches blockchain data structure including block header, this block header containing date, time block, reference to the previous block, “hash” block” particularly defining SHA-256 cryptographic algorithm, typically SHA-256 function applied to produce hash value, Salami’s SHA-256 cryptographic algorithm generates cryptographic identifier for blockchain node corresponds to corresponds to instant specification page 10 line 3 cryptographic unambiguous identifier)
Dourous teaches “where the non-primary validation node checks if the cryptographically unambiguous identifier created in step h) (0107, 0139-0140, fig 16)  and sends a commit message to all other validation nodes where the commit message is at least one of
i.  	“a first type of commit message sent only when the non-primary validation node has carried out step h) but not i)s  and the conditions for sending the second type of commit message is not fulfilled” (Dourous : 0112-0113,0119, fig 4)
ii.  	“a second type of commit message sent only when the validation node has received, from different validation nodes, a predetermined minimal number P of commit messages of the first type (Dourous : fig 4, 0119, 0121)
where step i) includes a validation node releasing its save point only when a predetermined number C of commit messages of the second type has been received from different validation nodes, and where C > P (Dourous: 0124-0125, fig 9-10)
As to claim 4, 15, Dourous  disclosed “where each of the validation nodes repeatedly, with a predetermined minimal time interval, sends out the commit messages of the first or second type to all other validation nodes, when conditions for sending such messages are fulfilled” (Dourous : 0105-0107).
As to claim 5, 18, Dourous disclosed “where each of the validation nodes repeatedly, with a predetermined minimal time interval, sends out a third type of commit message to all other validation nodes, the third type of commit message indicating that the sending validation node is in a state where the conditions for sending the first or second type of commit messages are not fulfilled” (Dourous :0107, 0112-01132).
As to claim 6,  Salami disclosed “where the transaction messages are signed with a digital signature” (Salami: 0035 0042, line 14-23, ECDSA is digital signature algorithm)
As to claim 7, Salami disclosed “where the data on which the cryptographically unambiguous identifier depends, additionally comprises a timestamp, or information about block height, (Salami: 0087,0090).
As to claim 8 ,Salami disclosed “where the cryptographically unambiguous identifier is a hash” (Salami : 0043 – Salami teaches hash ie., SHA-256 cryptographic algorithm).
As to claim 9 Dourous disclosed “where the primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step b)  (Dourous : 0132-0134).
As to claim 10 Dourous disclosed “where the non-primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step g)” (Douros: 0107, 0133-0134,0139-0140, fig 12,fig 16) .
As to claim 19, the combination of Salami,Douros, Gray disclosed:
wherein the software is run on a on a non-primary validation node, which is configured to:
receive a block message from a primary validation node (Salami: fig 1, 0028, line 1-4, 0048);
“provide the transaction message to the node relational database for execution, and if execution is successful”( Salami : 0039,0048):
“compute a cryptographically unambiguous identifier (CUI) of a data block, said data block comprising the at least one transaction message and the CUI of the immediately preceding block of the node” (Salami : 0043,0048, line 19-23,  page 8, 0049; and
“comparing the CUI received in the block message from the primary validation node with the CUI computed by the node, and, if the CUls are the same, to send a commit message to at least one validation node” (Salami : 0043,0048, 0102, 0104)
As to claim 11, the combination of Salami, Douros, Gray, disclosed  wherein said each of said node relational databases comprises: a first table comprising database information records; a second table comprising at least one transaction message that have modified at least one of said records” (Salami: fig 1, 0028-0029; fig 1A-1B) and  a third table comprising a plurality of cryptographically unambiguous identifiers (CUIs), where each CUI is a CUI of a data block, wherein each data block comprises at least the CUI of an immediately previously stored data block and at least one data block comprises at least one transaction message from the second table” (0043,0048,          line 19-23,  page 8, 0049, SHA-256 cryptographic algorithm,  typically SHA-256 function applied to produce hash value, Salami’s SHA-256 cryptographic algorithm generates cryptographic identifier for blockchain node corresponds to corresponds to instant specification page 10 line 3 cryptographic unambiguous identifier).
.
As to 12, the combination of Salami, Douros,Gray disclosed “ wherein each CUI in the third table is logically linked to one or more of the transaction messages in the second table” (Salami : 0043,0048, line 19-23)
Conclusion
The prior art made of record
a.  	US Pub. No.  	2017/0345011
b. 	US Pub. No. 		2017/0011085
c. 	US Pub. No. 		2017/0353309
d. 	US Pat. No. 		8,751,460
Examiner's Note: Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
SEE MPEP 2141.02 [R-5] VI. PRIOR ART MUST BE CONSIDERED IN ITS ENTIRETY, INCLUDING DISCLOSURES THAT TEACH AWAY FROM THE CLAIMS:  A prior art reference must be considered in its entirety, i.e., as a whole, including portions that would lead away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert. denied, 469 U.S. 851 (1984) In re Fulton, 391 F.3d 1195, 1201,73 USPQ2d 1141, 1146 (Fed. Cir. 2004). >See also MPEP §2123.
In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
The prior art made of record, listed on form PTO-892, and not relied upon, if any, is considered pertinent to applicant's disclosure
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.


NEXT OFFICE ACTION: Notice of Pre-AIA  or AIA  Status
The present application 17/719,933, filed on 4/13/2022 (or after March 16, 2013), is being examined under the first inventor to file provisions of the AIA  (First Inventor to File).
In the event the determination of the status of the application as subject to AIA  35 U.S.C. 102 and 103 (or as subject to pre-AIA  35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application is a CON of US Application # 16/628,563 filed on 01/03/2020 is now US PAT 11334678, US Application # 16/628,563 is a 371 of PCT/EP2018/068421 filed on 07/06/2018
DETAILED ACTION
Response to Amendment
Claims 1-19 are pending in this application
Examiner acknowledges applicant’s amendment filed on 8/31/2023
Drawings
The Drawings filed on 4/29/2022 are acceptable for examination purpose
Priority
Acknowledgment is made of applicant’s claim for Swedish Patent Application foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy of Swedish Patent application # 1750892-0  (7/6/2017) has been filed on 13/2020.
Response to Arguments
Applicant's arguments filed 8/31/2023 with rispetto claims 1-19 have been fully considered, for examiner’s response, see discussion below:
35 USC § 101
In view of applicant’s amendment, remarks filed on 8/31/2023, the rejection as set forth in the previous office action is hereby withdrawn.
Double Patenting
At page 12-13, examiner noted applicant’s remarks on double patent rejection, however, applicant may consider filing terminal disclaimer to overcome the double patent rejection, subject to approval.
At page 21, claim 1,13,16, applicant argues:
Salami is not at all interested in relational databases, in Salami, there is no way to control the order of transaction processing in a relational database system…..the present application provides a system and method for efficiently securing a distributed relational database using a blockchain
Examiner’s response:
As best understood by the examiner, the prior art of Salami teaches databases performing transactions for example as shown in fig 1A, para 0030  shows processing of transactions such as in a market parameter transactions  using databases in a blockchain environment and/or distributed database environment is identical to instant specification page 2, line 20-24, page 5, line 1-5
At page 23, claim 1,13,16, applicant argues:
Salami fails to disclose information is stored in a relational database and a blockchain that is maintained to better guarantee the validity …….database transactions……..
Examiner’s response:
As to the above argument, as best understood by the examiner, the prior art of Salami teaches blockchain nodes and synchronized across nodes and each blockchain node corresponds to database because each respective blockchain node in a database such as the state database as detailed in 0048, line 19-21, it is also noted that Salami teaches blockchain node receives and validates the transaction particularly transaction
signature assigned public key, thus validation blockchain nodes of respective database maintains validated transactions (Salami: 0028, line 1-4, 0048, line 19-21,  0052, 0090, fig 1A-1B)
At page 24, claim 1,13,16, applicant argues:
Salami fails to disclose save points that are used to be able to tentatively process database transactions
Examiner’s response:
As best understood by the examiner, the prior art of Salami teaches blockchain node database determines not only validating transaction, public key signature of the respective message and as such each blockchain node and the initial state containing the time and date corresponds to save point because each transaction validation message maintains timestamp (page 6, 0037 line 1-2, page 7, para 0037, line 1-6, line -0039), further, the prior art of Salami  maintains transaction state on each transaction in the database of  respective blockchain node and determines updates accordingly (Salami:0058)
At page 25, claim 1,13,16, applicant argues:
Salami does not disclose the claimed mechanism of a primary node applying database instructions of a transaction message and a non-primary node………..
At page 26, applicant argues:
Neither Salami nor Douros nor their combination teach or suggest claim 1 as amended
Examiner’s response:
As best understood by the examiner, the prior art of Salami teaches relational database transactions in a distributed databases associated with the blockchain including messages (Salami: Abstract, fig 1A-B, 0037,0058).  On the other hand,
Douros teaches distributed database nodes and transactions particularly each transaction message generates commit identifier determines whether any conflicts and/or safe commits, during determination process identifies transaction state such as abort, suspend and preparing state, further, Douros also teaches examining time intervals for each transaction of both primary validation and non-primary validation with respect to time for validation phrase that including messages/phases associated with the transaction as detailed in 0107, 0139-0140, fig 16.  It is further noted that the prior art of Salami,Douros, Gray do not suggest “SQL relational database, although Dourous teaches relational database system particularly distributed relational database system and respective transactions (Dourous: 0003).  On the other hand, Massari disclosed SQL relational database (Massari: Abstract, fig 1 SQL clients, fig 1).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention modeling within distributed databases particularly executing transactions using SQL operations of Massari et al., into users of Salami, Douros and Gray because that would have allowed users of Salami, Dourous, Gray to use specific SQL commands during the distributed database transactions across all the database nodes (Massari: Abstract,0029,0048).
Examiner applies above arguments to claims 13, 16, and claims 2-12,14-15,17-19 depend from claim 1,13,16 respectively.
Statutory Review under 35 USC § 101
Claims 1-12 are directed towards a method and have been reviewed.
Claims 1-12 perform the method steps, determined to be directed to significantly more than an abstract idea based on currently known judicial exceptions.
Claims 13-15 are directed toward a system and have been reviewed.
Claim 13-15 appear to be statutory, as the system includes hardware (at least one data processor) as disclosed in ¶ page 7, line 6-18, fig 2 of the applicant’s specification referring to physical processor cores.
Claims 16-19 are directed to a non-transitory computer readable memory storing software thereon that when executed by a computer performs a method for synchronization of node relational database in a relational database system, said relational database system comprising a plurality of validation nodes each comprising a node relational database, and have been reviewed.
Claims 16-19 appear to be statutory, as the claim says non-transitory.
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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used.  Please visit http://www.uspto.gov/forms/.  The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-19 of US Application No. 17/719,933 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-12 of U.S. Patent No. 11,334,678. Although the claims at issue are not identical, they are not patentably distinct from each other because the patented claims perform the same steps as the claims in the instant application.
Instant US application: 17/719,933
US Patent No. 11,334,678
Claim 1,13,19, A method for synchronization of node structured query language (SQL) relational databases in an SQL relational database system and replicating data across nodes in the SQL relational database system, said SQL relational database system comprising a plurality of validation nodes each comprising a node relational database, each node relational database being an SQL database, each node relational database further being a copy of one and the same relational database, the copies across different validation nodes possibly differing due to lag of transactions, downtime of a validation node or network downtime, and, optionally, the database system further comprising one or more client where one of the plurality of validation nodes is a primary validation node, the primary validation node having received a transaction message from another validation node or the client node, the transaction message comprising to instructions modify data records in the node relational databases, where each of the validation nodes stores, in its node relational database, a respective chain of data blocks, where each data block in the chain of data blocks comprises at least a cryptographically unambiguous identifier(CUI) of a previous data block, each block further comprising one or more ordered transaction messages, the one or several transaction messages being ordered so that they are executed in a predetermined order, the method comprising:
a) the primary validation node making a save point for a primary validation node relational database of the primary node, the save point creating a state of the primary validation node relational database to which the primary validation node relational database can be reverted to, at a later point in time, so that the primary validation node can carry out the instructions in the transaction message and later roll back the primary validation node relational database to the state of the primary validation node relational database present before the save point;
b) the primary validation node attempting to carry out the instructions in the transaction message and, if the attempt to carry out the instructions is successful:
c) the primary validation node storing a data block in the primary validation node relational database, said data block comprising the at least one transaction message;
and
d) the primary validation node creating a (CUI) of the data in the block;
e) the primary validation node sending a block message to a non-primary validation node of the plurality of validation nodes, the block message comprising the data block and the CIU of the data block;
f) the non-primary validation node receiving the block message, and creating a save point for a non-primary validation node relational database of the non-primary validation node, the save point creating a state of the non-primary validation node relational database to which the non-primary validation node relational database can be reverted to at a later point in time so that the non-primary validation node tentatively can carry out the instructions in the transaction message and later roll back the non-primary validation node relational database to the state of the non-primary validation node relational database present before the save point;
g) the non-primary validation node attempting to carry out the instructions in the transaction message in the block message so as to arrive at a non-primary validation node relational database that matches the primary validation node relational database and, if successful, storing a data block in the non-primary validation node relational database, the data block comprising the at least one transaction message;
h) the non-primary validation node creating a CUI of the data in the data block; and
i) the primary and non-primary validation nodes removing their respective save  points based on a predetermined number of the plurality of validation nodes having achieved identical blocks, wherein a determination of whether the primary and non- primary validation nodes have achieved identical blocks comprises using a consensus algorithm.
2. The method of claim 1 wherein the primary validation node making the save point for the primary validation node relational database comprises the primary validation node, after creating the save point, creating a nested save point that enables rollback of a transaction, and releasing that the nested save point if the transaction is carried out successfully
4. The method of claim 3 where each of the validation nodes repeatedly, with a predetermined minimal time interval, sends out the commit messages of the first or second type to all other validation nodes, when conditions for sending such messages are fulfilled.
6. The method according to claim 1 where the transaction messages are signed with a digital signature
7.  where the data on which the CUI depends, additionally comprises a timestamp, or information about block height,
8. The method according to claim 1 where the CUI is a hash.
10. The method according to claim 1 where the non-primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step g).
Claim 1, 11, A method for synchronization of node relational relational database in a relational database system, said relational database system comprising a plurality of validation nodes each comprising a node relational database and, optionally, client node, where one of the plurality of validation nodes is a primary validation node, the primary validation node having received at a transaction message from another validation node or the client node, the transaction message comprising an instruction to modify the node relational relational database, where each of the validation nodes stores, in its node relational database, a chain of data blocks, where each data block in the chain of data blocks comprises at least a cryptographically unambiguous identifier of a previous data block, each block further comprising one or more ordered transaction messages, the method comprising:
a) the primary validation node making a save point for a primary validation node relational database of the primary validation node, the save point creating a state of the primary validation node relational database to which the primary validation node relational database can be reverted to, at a later point in time, so that the primary validation node can carry out the instruction in the transaction message and later roll back the primary validation node relational database to the state of the primary validation node relational database present before the save point,
b) the primary validation node attempting to carry out the instruction in the transaction message and, if the attempt to carry out the instruction is successful:
c) the primary validation node storing a data block in the primary validation node relational database, said data block comprising the at least one transaction message,
d) the primary validation node creating a cryptographically unambiguous identifier (CUD) of the data in the block,
e) the primary validation node sending a block message to a non-primary validation node of the plurality of validation nodes, the block message comprising the data block and the cryptographically unambiguous identifier of the data block,
f) the non-primary validation node receiving the block message, and creating a save point for a non-primary validation node relational database of the non-primary validation node, the save point creating a state of the non-primary validation node relational database to which the non-primary validation node relational database can be reverted to at a later point in time so that the non-primary validation node tentatively can carry out the instruction in the transaction message and later roll back the non-primary validation node relational database to the state of the non-primary validation node relational database present before the save point,
g) the non-primary validation node attempting to carry out the instruction in the transaction message in the block message so as to arrive at a non-primary validation node relational database that is the same as a state of the primary validation node relational database and, if successful, storing a data block in the non-primary validation node relational database, the data block comprising the at least one transaction message,
h) the non-primary validation node creating a cryptographically unambiguous identifier of the data in the data block,
i) the primary and non-primary validation nodes removing their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blocks, wherein a determination of whether the primary and non-primary validation nodes have achieved identical blocks comprises using a consensus algorithm,
wherein the non-primary validation node checks whether the cryptographically unambiguous identifier created in step h) corresponds to the cryptographically unambiguous identifier received in step f), and sends a commit message to the plurality of validation nodes wherein the commit message comprises at least one of:
i. a first type of commit message sent only when the non-primary validation node has carried out step h) but not i), and the conditions for sending the second type of commit message is not fulfilled,
ii. a second type of commit message sent only when the validation node has received, from different validation nodes, a predetermined minimal number P of commit messages of the first type,
wherein step i) comprises a validation node releasing its save point only when a predetermined number C of commit messages of the second type has been received from different validation nodes, and where C>P,
wherein each of the plurality of validation nodes repeatedly, with a predetermined minimal time interval, sends out a third type of commit message to all other validation nodes of the plurality of validation nodes, the third type of commit message indicating that the validation node sending the third type of commit message is in a state wherein conditions for sending either the first and/or the second type of commit messages are not fulfilled.
2. The method of claim 1 wherein the primary validation node making the save point for the primary validation node relational database comprises the primary validation node, after creating the save point, creating a nested save point that enables rollback of a transaction, and releasing that the nested save point if the transaction is carried out successfully.
3. The method of claim 1 where each of the validation nodes repeatedly, with a predetermined minimal time interval, sends out the commit messages of the first or second type to all other validation nodes, when conditions for sending such messages are fulfilled
4. The method according to claim 1 where the transaction messages are signed with a digital signature.
5.  where the data on which the cryptographically unambiguous identifier depends, additionally comprises a timestamp, or information about block height,
6. The method according to claim 1 where the cryptographically unambiguous identifier is a hash.
8. The method according to claim 1 where the non-primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step g).
It would have been obvious to a person of ordinary skill was made to modify and/or to omit the additional elements of claim 1-12 of U.S. Patent No. 11,334,678 to arrive at the claims 1-19 of the instant application 17/719,933 because the ordinary skilled person would have realized that the remaining element(s) would perform the same function as before as shown above underlined limitations while  claim 1 of U.S. Patent No. 11,334,678,  wherein the non-primary validation node checks whether the cryptographically unambiguous identifier created in step h) corresponds to the cryptographically unambiguous identifier received in step f), and sends a commit message to the plurality of validation nodes wherein the commit message comprises at least one of:
i. a first type of commit message sent only when the non-primary validation node has carried out step h) but not i), and the conditions for sending the second type of commit message is not fulfilled,
ii. a second type of commit message sent only when the validation node has received, from different validation nodes, a predetermined minimal number P of commit messages of the first type,
wherein step i) comprises a validation node releasing its save point only when a predetermined number C of commit messages of the second type has been received from different validation nodes, and where C>P,
wherein each of the plurality of validation nodes repeatedly, with a predetermined minimal time interval, sends out a third type of commit message to all other validation nodes of the plurality of validation nodes, the third type of commit message indicating that the validation node sending the third type of commit message is in a state wherein conditions for sending either the first and/or the second type of commit messages are not fulfilled,  is absent of the limitation from instant application 17/719,933 claim 1, 13,16.  Omission and/or addition of elements and its function in combination is obvious expedient if the remaining elements perform same functions as before, as such instant application 17/719,933 claim 1, 13,16 are broader.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
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-19  is/are rejected under 35 U.S.C. 103 as being unpatentable over Salami et al., (hereafter Salami), US Pub.No. 2017/0345011 filed on May,2016, Douros et al., (hereafter Douros), US Pub.No. 2017/0011085 based on provisional application filed on Jul,2015 in view of Gray, US Pub.No. 2017/0353309 based on provisional application filed on Jun,2016, Massari et al., (hereafter Massari), US Pub. No. 2016/0371355 published Dec,2016.
As to claim 1, 13,16  Salami teaches a system which including “A method for synchronization of node relational databases in an relational database system and replicating data across nodes in the relational database system, said relational database system comprising a plurality of validation nodes each comprising a node relational database, each node relational database being an database” (0028, line 1-4, 0048, line 19-21,  0052, 0090, fig 1A-1B – Salami teaches blockchain nodes and synchronized across nodes and each blockchain node corresponds to database because each respective blockchain node in a database such as the state database as detailed in 0048, line 19-21, it is also noted that Salami teaches blockchain node receives and validates the transaction particularly transaction signature assigned public key, thus validation blockchain nodes of respective database maintains validated transactions),“ each node relational database further being a copy of one and the same relational database, the copies across different validation nodes possibly differing due to lag of transactions (Salami : fig 1A-1B ,0026-0027– Salami teaches multiple blockchain nodes connected in a client-server or peer-to-peer or distributed network, while first blockchain, second blockchain node represents respective database copies controlled by the participant computer systems because the activities and/or transactions are required to synchronize across blockchain database nodes and each the computer code validation from the respective  nodes),” downtime of a validation node or network downtime” (Salami: 0071-0072 – Salami teaches blockchain nodes receive and validate the transactions, while monitoring blockchain records are loaded into the state database identifying transaction during downtime of validation process) and, optionally, the database system further comprising one or more client (fig 1A-1B – Salami teaches multiple blockchain nodes connected in a client-server or peer-to-peer or distributed network environment);
“where one of the plurality of validation nodes is a primary validation node” (fig 1, 0097 – Salami teaches multiple blockchain nodes in a distributed computing environment, validating blockchain node or set of validating blockchain nodes, while each blockchain node acts as primary validation node due to respective transaction received and independently computes new state as detailed in 0097),
the primary validation node having received at least one transaction message from another validation node or a client, the transaction message comprising instructions to modify the node relational database, where each of the nodes stores, in its node database, a chain of data blocks, where each data block in the block chain     (fig 1, 0028, line 1-4, 0048 – Salami teaches blockchain nodes connected in a distributed computing network environment, and each blockchain node in a database  for example state of the database with respect to validation and transaction because transactions within the that block to the state of the database is applied , further each transaction associated with the respective message indicating the status of the transaction and/or update on to the node database state) comprises at least a cryptographically unambiguous identifier of the previous data block (0043,0048, line 19-23, page 8, 0049 – Salami teaches blockchain data structure including block header, this block header containing date, time block, reference to the previous block, “hash” block” particularly defining SHA-256 cryptographic algorithm, typically SHA-256 function applied to produce hash value, Salami’s SHA-256 cryptographic algorithm generates cryptographic identifier for blockchain node corresponds to corresponds to instant specification page 10 line 3 cryptographic unambiguous identifier),”each block further comprising one or more ordered transaction messages, the one or several transaction messages being ordered so that they are executed in a predetermined order  the method comprising the steps of, in order: (Salami: 0078-0079)
“a) the primary validation node making a save point for the primary validation node database” (Salami: 0038 – Salami teaches blockchain node that receives and validates the transaction corresponds to primary node validation particularly transaction signature associated with the message), “the save point creating a state of the primary validation node database to which the primary validation node database can be reverted to, at a later point in time” (Salami: page 6, 0037 line 1-2, page 7, para 0037, line 1-6, line -0039 – Salami teaches blockchain node database determines not only validating transaction, public key signature of the respective message and as such each blockchain node and the initial state containing the time and date corresponds to save point because each transaction validation message maintains timestamp)
“b) the primary validation node attempting to carry out the instructions in the at least one transaction message and, if attempt is successful” (0069, 0071 – Salami teaches each transaction validation  and the message, particularly process the transaction send and/or receive associated with the message thereby it indicates transaction successful)
“c) the primary validation node storing a data block in the node database, said data block comprising the at least one transaction message” (0039,0048 – Salami teaches blockchain nodes database arranged in tree node structure and each primary node validation with respect to the node state database)  and
“d) the primary validation node creating a cryptographically unambiguous identifier of the data in the block” (0043, 0048 – Salami teaches SHA-256 cryptographic algorithm is identical to instant specification page 4, line 14),
“e) the primary validation node sending a block message to the at least one non-primary validation node, the block message comprising the data block and the cryptographically unambiguous identifier of the data block” (0043,0048, line 19-23,  page 8, 0049 – Salami teaches blockchain data structure including block header, this block header containing date, time block, reference to the previous block, “hash” block” particularly defining SHA-256 cryptographic algorithm, typically SHA-256 function applied to produce hash value, Salami’s SHA-256 cryptographic algorithm generates cryptographic identifier for blockchain node corresponds to corresponds to instant specification page 4, line 14, page 10 line 3 cryptographic unambiguous identifier),
“f) creating a save point for the node database” (Salami: page 6, 0037 line 1-2, page 7, para 0037, line 1-6, line -0039 – Salami teaches blockchain node database determines not only validating transaction, public key signature of the respective message and as such each blockchain node and the initial state containing the time and date corresponds to save point because each transaction validation message maintains timestamp),
“g) primary validation node attempting to carry out the instruction in the transaction message in the block message and, if 2successful” (0039,0048 – Salami teaches blockchain nodes database arranged in tree node structure and each primary node validation with respect to the node state database); “storing a data block in the node database, the data block comprising the at least one transaction message” (0097 – Salami teaches blockchain nodes, transactions associated with the messages and their state stored in the temporary working memory known as “mempool” until a new, valid block that includes the transaction is received),
“h) the at least one non-primary validation node creating a cryptographically unambiguous identifier of the data in the data block”(Salami:  0043,0048, line 19-23,  page 8, 0049 – Salami teaches blockchain data structure including block header, this block header containing date, time block, reference to the previous block, “hash” block” particularly defining SHA-256 cryptographic algorithm, typically SHA-256 function applied to produce hash value, Salami’s SHA-256 cryptographic algorithm generates cryptographic identifier for blockchain node corresponds to corresponds to instant specification page 4, line 14, page 10 line 3 cryptographic unambiguous identifier),
“i) the validation nodes removing their save points if a predetermined number of validation nodes has achieved identical blocks” (Salami: 0102, 0104 – Salami teaches blockchain nodes validation process particularly with respect to update function, further Salami teaches synchronization, validation of data across blockchain nodes, thereby eliminating other blockchain node(s) in a distributed computing environment)
It is however, noted that Salami does not disclose “f) the at least one non-primary validation node receiving the block message, the at least one non-primary validation node attempting to carry out the instruction in the transaction message”.  On the other hand, Douros disclosed f) the at least one non-primary validation node receiving the block message,  the at least one non-primary validation node attempting to carry out the instruction in the transaction message” (Douros: 0107, 0139-0140, fig 16 – Douros teaches distributed database nodes and transactions particularly each transaction message generates commit identifier determines whether any conflicts and/or safe commits, during determination process identifies transaction state such as abort, suspend and preparing state, further, Douros also teaches examining time intervals for each transaction of both primary validation and non-primary validation with respect to time for validation phrase that including messages/phases associated with the transaction as detailed in 0107).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine concurrent transaction particularly transactions includes determining time of imitation maintain plurality of nodes, records of transactions in a distributed database system of  Douros et al., with blockchain nodes configured in a distributed computing environment of Salami because that would have allowed users of Salami to identify list of transactions of each node, transaction state and sending and receiving messages from the each node, while performing validation phase to identify priority and non-priority nodes ,ie., designating “priority or leader” node that is responsible for assigning transaction identifiers to new transactions (Douros: 0103), further delaying non-priority transaction allows improving optimized distributed database operations including both read and write transactions, thus transaction manager may resolve conflict resolution between concurrent transaction while maintain atomicity of transactions (Douros: 0049-0050)
It is however, noted that Salami, Douros do not disclose “where the determination if the validation nodes have achieved identical blocks is done using a consensus algorithm, although Salami teaches validation blockchain database nodes(Salami: fig 1-2, fig 7, element 106,108,110,112); prior art of Douros teaches time intervals associated with the transactions and validation phrase (Douros: 0107).          On the other hand, Gray disclosed “where the determination if the validation nodes   have achieved identical blocks is done using a consensus algorithm” (0007, 0052-0054 – Gary teaches cryptlet to execute on blockchain database node first validating the transaction, perform actions in a enterprise network environment, ie., each node employs consensus algorithm to decide on which transactions to keep and discard, while each node in the blockchain ensures integrity and authenticity as detailed in 0007.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine cryptographic applications in blockchain system of Gray into users of Salami,Dourous because that would have allowed users of Salami,Dourous to define smart contract associated with a blockchain particularly crypted of Gary to perform required transactions, while validating the message associated with the transactions (Gary: 0009), it is noted that Gray’s cryptlet provides response to the cryptodelegate and blockchain (Gary:0019, line 23-25), thus improves secure and authentic transaction in a distributed computing environment (Gray: 0025).  It is however noted that, Salami, Douros and Gray do not teach “SQL relational database, although Dourous teaches relational database system particularly distributed relational database system and respective transactions (Dourous: 0003).  On the other hand, Massari disclosed SQL relational database (Massari: Abstract, fig 1 SQL clients, fig 1).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention modeling within distributed databases particularly executing transactions using SQL operations of Massari et al., into users of Salami, Douros and Gray because that would have allowed users of Salami,Dourous, Gray to use specific SQL commands during the distributed database transactions across all the database nodes (Massari: Abstract,0029,0048).
As to claim 2, Dourous  disclosed  “wherein the primary validation node making the save point for the primary validation node relational database comprises the primary validation node, after creating the save point, creating a nested save point that enables rollback of a transaction, and releasing that the nested save point if the transaction is carried out successfully” ( Dourous: 0161-0163, fig 29 – Dourous teaches transaction manager of nodes identifying and completing transaction writing  i.e., prepare state at the participating nodes, validating and sending message of the identified transactions, further if any transaction cannot be committed, Dourous’s algorithm finally, identifies particular node transaction’s changes are rolled back)
As to claim 3, 14,17, Salami disclosed the CUI received in step f), (0043,0048, line 19-23, page 8, 0049 – Salami teaches blockchain data structure including block header, this block header containing date, time block, reference to the previous block, “hash” block” particularly defining SHA-256 cryptographic algorithm, typically SHA-256 function applied to produce hash value, Salami’s SHA-256 cryptographic algorithm generates cryptographic identifier for blockchain node corresponds to corresponds to instant specification page 10 line 3 cryptographic unambiguous identifier)
Dourous teaches “where the non-primary validation node checks if the CUI created in step h) (0107, 0139-0140, fig 16)  and sends a commit message to all other validation nodes where the commit message is at least one of
i.  	“a first type of commit message sent only when the non-primary validation node has carried out step h) but not i)s  and the conditions for sending the second type of commit message is not fulfilled” (Dourous : 0112-0113,0119, fig 4)
ii.  	“a second type of commit message sent only when the validation node has received, from different validation nodes, a predetermined minimal number P of commit messages of the first type (Dourous : fig 4, 0119, 0121)
where step i) includes a validation node releasing its save point only when a predetermined number C of commit messages of the second type has been received from different validation nodes, and where C > P (Dourous: 0124-0125, fig 9-10)
As to claim 4, 15, Dourous  disclosed “where each of the validation nodes repeatedly, with a predetermined minimal time interval, sends out the commit messages of the first or second type to all other validation nodes, when conditions for sending such messages are fulfilled” (Dourous : 0105-0107).
As to claim 5, 18, Dourous disclosed “where each of the validation nodes repeatedly, with a predetermined minimal time interval, sends out a third type of commit message to all other validation nodes, the third type of commit message indicating that the sending validation node is in a state where the conditions for sending the first or second type of commit messages are not fulfilled” (Dourous :0107, 0112-01132).
As to claim 6,  Salami disclosed “where the transaction messages are signed with a digital signature” (Salami: 0035 0042, line 14-23, ECDSA is digital signature algorithm)
As to claim 7, Salami disclosed “where the data on which the CUI depends, additionally comprises a timestamp, or information about block height, (Salami: 0087,0090).
As to claim 8 ,Salami disclosed “where the CUI is a hash” (Salami : 0043 – Salami teaches hash ie., SHA-256 cryptographic algorithm).
As to claim 9 Dourous disclosed “where the primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step b)  (Dourous : 0132-0134).
As to claim 10 Dourous disclosed “where the non-primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step g)” (Douros: 0107, 0133-0134,0139-0140, fig 12,fig 16)
As to claim 11, the combination of Salami, Douros, Gray, Massari, disclosed  wherein said each of said node relational databases comprises: a first table comprising database information records; a second table comprising at least one transaction message that have modified at least one of said records” (Salami: fig 1, 0028-0029; fig 1A-1B) and  a third table comprising a plurality of CUIs, where each CUI is a CUI of a data block, wherein each data block comprises at least the CUI of an immediately previously stored data block and at least one data block comprises at least one transaction message from the second table” (0043,0048, line 19-23,  page 8, 0049, SHA-256 cryptographic algorithm,  typically SHA-256 function applied to produce hash value, Salami’s SHA-256 cryptographic algorithm generates cryptographic identifier for blockchain node corresponds to corresponds to instant specification page 10 line 3 cryptographic unambiguous identifier).
.
As to 12, the combination of Salami, Douros,Gray disclosed “ wherein each CUI in the third table is logically linked to one or more of the transaction messages in the second table” (Salami : 0043,0048, line 19-23)
As to claim 19, the combination of Salami, Douros, Gray, Massari disclosed:
wherein the software is run on a on a non-primary validation node, which is configured to:
receive a block message from a primary validation node (Salami: fig 1, 0028, line 1-4, 0048);
“provide the transaction message to the node relational database for execution, and if execution is successful”( Salami : 0039,0048):
“compute a CUI of a data block, said data block comprising the at least one transaction message and the CUI of the immediately preceding block of the node” (Salami : 0043,0048, line 19-23,  page 8, 0049; and
“comparing the CUI received in the block message from the primary validation node with the CUI computed by the node, and, if the CUls are the same, to send a commit message to at least one validation node” (Salami : 0043,0048, 0102, 0104)
Conclusion
The prior art made of record
a.  	US Pub. No.  	2017/0345011
b. 	US Pub. No. 		2017/0011085
c. 	US Pub. No. 		2017/0353309
d. 	US Pub. No. 		2016/0371355
Examiner's Note: Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
SEE MPEP 2141.02 [R-5] VI. PRIOR ART MUST BE CONSIDERED IN ITS ENTIRETY, INCLUDING DISCLOSURES THAT TEACH AWAY FROM THE CLAIMS:  A prior art reference must be considered in its entirety, i.e., as a whole, including portions that would lead away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert. denied, 469 U.S. 851 (1984) In re Fulton, 391 F.3d 1195, 1201,73 USPQ2d 1141, 1146 (Fed. Cir. 2004). >See also MPEP §2123.
In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
The prior art made of record, listed on form PTO-892, and not relied upon, if any, is considered pertinent to applicant's disclosure
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
THIS ACTION IS MADE FINAL.  Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action.  In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action.  In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.

CITED REFERENCE SUMMARIES: Ref US20170345011A1: Claims:
- 45 . (canceled)
A method of updating a balance, comprising: distributing a computer code to a plurality of nodes; distributing a first state to first and second ones of the nodes such that each node has a copy of the first state; causing a state transition from the first state to a second state at the first node, the state transition including a determination of a transfer amount and an adjustment of a balance based on the transfer amount; transmitting at least an indication of the state transition from the first node to a validation node other than the first node; receiving the indication of the state transition from the first node at the validation node; calculating, with the computer code at the validation node, the second state; and updating the state on the second node to the second state if the state transition calculated by the validation node matches the state transition of the first node.
distributing a computer code to a plurality of nodes;
distributing a first state to first and second ones of the nodes such that each node has a copy of the first state;
causing a state transition from the first state to a second state at the first node, the state transition including a determination of a transfer amount and an adjustment of a balance based on the transfer amount;
transmitting at least an indication of the state transition from the first node to a validation node other than the first node;
receiving the indication of the state transition from the first node at the validation node;
calculating, with the computer code at the validation node, the second state; and
updating the state on the second node to the second state if the state transition calculated by the validation node matches the state transition of the first node.
The method of claim 46 , wherein the validation node is a third node other than the first node or the second node, further comprising: transmitting a validation from the third node to the second node; and receiving the validation from the third node at the second node, wherein the second node only updates the first state to the second state if the validation is received.
transmitting a validation from the third node to the second node; and
receiving the validation from the third node at the second node, wherein the second node only updates the first state to the second state if the validation is received.
The method of claim 47 , wherein the first node sends the state transition to the second and third nodes before the second node receives the validation from the third node.
The method of claim 46 , further comprising: transmitting a validation from the validation node to the first node; receiving the validation from the validation node at the first node; and applying the state transition at the first node only if the validation is received.
transmitting a validation from the validation node to the first node;
receiving the validation from the validation node at the first node; and
applying the state transition at the first node only if the validation is received.
The method of claim 46 , wherein the transfer is from a balance of a first user to a balance of a second user.
The method of claim 46 , wherein the transfer is from a first balance of a first user controlled by the code without allowing the first user to withdraw funds to reduce the first balance to a second balance of the first user from which the first user is able to make a withdrawal.
Ref US20170011085A1: Claims:
A method for managing potentially concurrent transactions in a distributed database system including a plurality of nodes, the method including: maintaining, at a first node of the plurality of nodes, records of a plurality of transactions, each transaction executing on one or more of the plurality of nodes, each record having a transaction state of a plurality of transaction states, the records including a record for a first transaction and a record for a second transaction, execution of the first transaction at a second node of the plurality of nodes including an operation for accessing a first data element stored on the second node and execution of the second transaction at the second node including an operation for accessing the first data element stored on the second node; receiving, at the second node from the first node, a list of transactions that includes any of the plurality of transactions executing on the second node and having a first transaction state at a time of initiation of the second transaction, the list of transactions including the first transaction; determining that an outcome of the second transaction depends on an outcome of the first transaction based at least in part on the list of transactions; and suspending execution of the second transaction until after the first transaction is complete based on the determining.
maintaining, at a first node of the plurality of nodes, records of a plurality of transactions, each transaction executing on one or more of the plurality of nodes, each record having a transaction state of a plurality of transaction states, the records including a record for a first transaction and a record for a second transaction, execution of the first transaction at a second node of the plurality of nodes including an operation for accessing a first data element stored on the second node and execution of the second transaction at the second node including an operation for accessing the first data element stored on the second node;
receiving, at the second node from the first node, a list of transactions that includes any of the plurality of transactions executing on the second node and having a first transaction state at a time of initiation of the second transaction, the list of transactions including the first transaction;
determining that an outcome of the second transaction depends on an outcome of the first transaction based at least in part on the list of transactions; and
suspending execution of the second transaction until after the first transaction is complete based on the determining.
The method of claim 1 wherein determining that an outcome of the second transaction depends on an outcome of the first transaction based at least in part on the list of transactions includes determining that a time of initiation of the first transaction occurs prior to the time of initiation of the second transaction and that a commit time of the first transaction occurs prior to the time of initiation of the second transaction.
The method of claim 2 wherein the list of transactions is received at the second node at the time of initiation of the second transaction.
The method of claim 1 wherein the transactions included in the list of transactions consist of the transactions executing on the second node and having the first transaction state at the time of initiation of the second transaction.
The method of claim 1 wherein the list of transactions includes, for each transaction in the list of transactions, a time of initiation of the transaction.
The method of claim 1 wherein the first transaction state indicates that a transaction is preparing to complete.
The method of claim 1 wherein the first transaction writes the first data element and the second transaction reads the first data element, and a version of the first data element read by the second transaction depends on the outcome of the first transaction.
The method of claim 7 wherein possible outcomes of the first transaction include a transaction aborted outcome and a transaction committed outcome.
The method of claim 8 further including resuming execution of the second transaction after completion of the first transaction, including reading a first version of the first data element if the outcome of the first transaction is the transaction aborted outcome.
The method of claim 8 further including resuming execution of the second transaction after completion of the first transaction, including reading a second, different version of the first data element written by the first transaction if the outcome of the first transaction is the transaction committed outcome.
The method of claim 1 wherein one or both of the first transaction and the second transaction accesses data elements stored on a third node of the plurality of nodes.
The method of claim 1 wherein both the first transaction and the second transaction attempt to write the first data element and the second transaction is in the first transaction state.
The method of claim 12 wherein determining that an outcome of the second transaction depends on an outcome of the first transaction based at least in part on the list of transactions includes determining that a time of initiation of the second transaction occurs after a time of initiation of the first transaction and before a commit time of the first transaction.
The method of claim 12 wherein the first transaction is scheduled to commit its write before the second transaction and whether or not the second transaction is aborted depends on whether the first transaction results in a transaction aborted outcome or a transaction committed outcome.
The method of claim 14 further including resuming execution of the second transaction after completion of the first transaction, including writing a first value of the first data element if the outcome of the first transaction is the transaction aborted outcome.
The method of claim 14 further including resuming execution of the second transaction after completion of the first transaction, including aborting the second transaction if the outcome of the first transaction is the transaction committed outcome.
Software stored in a non-transitory form on a computer-readable medium, for managing potentially concurrent transactions in a distributed database system including a plurality of nodes, the software including instructions for causing a computing system to: maintain, at a first node of the plurality of nodes, records of a plurality of transactions, each transaction executing on one or more of the plurality of nodes, each record having a transaction state of a plurality of transaction states, the records including a record for a first transaction and a record for a second transaction, execution of the first transaction at a second node of the plurality of nodes including an operation for accessing a first data element stored on the second node and execution of the second transaction at the second node including an operation for accessing the first data element stored on the second node; receive, at the second node from the first node, a list of transactions that includes any of the plurality of transactions executing on the second node and having a first transaction state at a time of initiation of the second transaction, the list of transactions including the first transaction; determine that an outcome of the second transaction depends on an outcome of the first transaction based at least in part on the list of transactions; and suspend execution of the second transaction until after the first transaction is complete based on the determining.
maintain, at a first node of the plurality of nodes, records of a plurality of transactions, each transaction executing on one or more of the plurality of nodes, each record having a transaction state of a plurality of transaction states, the records including a record for a first transaction and a record for a second transaction, execution of the first transaction at a second node of the plurality of nodes including an operation for accessing a first data element stored on the second node and execution of the second transaction at the second node including an operation for accessing the first data element stored on the second node;
receive, at the second node from the first node, a list of transactions that includes any of the plurality of transactions executing on the second node and having a first transaction state at a time of initiation of the second transaction, the list of transactions including the first transaction;
determine that an outcome of the second transaction depends on an outcome of the first transaction based at least in part on the list of transactions; and
suspend execution of the second transaction until after the first transaction is complete based on the determining.
An apparatus for managing potentially concurrent transactions, the apparatus including: a plurality of nodes arranged in a distributed database system, each node including at least one processor; and a communication medium connecting ports of the plurality of nodes for sending and receiving information between the plurality of nodes; wherein a first node of the plurality of nodes is configured to maintain records of a plurality of transactions, each transaction executing on one or more of the plurality of nodes, each record having a transaction state of a plurality of transaction states, the records including a record for a first transaction and a record for a second transaction, execution of the first transaction at a second node of the plurality of nodes including an operation for accessing a first data element stored on the second node and execution of the second transaction at the second node including an operation for accessing the first data element stored on the second node; wherein the second node is configured to receive, from the first node, a list of transactions that includes any of the plurality of transactions executing on the second node and having a first transaction state at a time of initiation of the second transaction, the list of transactions including the first transaction; wherein the second node is configured to determine that an outcome of the second transaction depends on an outcome of the first transaction based at least in part on the list of transactions; and wherein the second node is configured suspend execution of the second transaction until after the first transaction is complete based on the determining.
a plurality of nodes arranged in a distributed database system, each node including at least one processor; and
a communication medium connecting ports of the plurality of nodes for sending and receiving information between the plurality of nodes;
wherein a first node of the plurality of nodes is configured to maintain records of a plurality of transactions, each transaction executing on one or more of the plurality of nodes, each record having a transaction state of a plurality of transaction states, the records including a record for a first transaction and a record for a second transaction, execution of the first transaction at a second node of the plurality of nodes including an operation for accessing a first data element stored on the second node and execution of the second transaction at the second node including an operation for accessing the first data element stored on the second node;
wherein the second node is configured to receive, from the first node, a list of transactions that includes any of the plurality of transactions executing on the second node and having a first transaction state at a time of initiation of the second transaction, the list of transactions including the first transaction;
wherein the second node is configured to determine that an outcome of the second transaction depends on an outcome of the first transaction based at least in part on the list of transactions; and
wherein the second node is configured suspend execution of the second transaction until after the first transaction is complete based on the determining.
A computing system for managing potentially concurrent transactions in a distributed database system including a plurality of nodes, the computing system including: means for maintaining, at a first node of the plurality of nodes, records of a plurality of transactions, each transaction executing on one or more of the plurality of nodes, each record having a transaction state of a plurality of transaction states, the records including a record for a first transaction and a record for a second transaction, execution of the first transaction at a second node of the plurality of nodes including an operation for accessing a first data element stored on the second node and execution of the second transaction at the second node including an operation for accessing the first data element stored on the second node; means for receiving, at the second node from the first node, a list of transactions that includes any of the plurality of transactions executing on the second node and having a first transaction state at a time of initiation of the second transaction, the list of transactions including the first transaction; means for determining that an outcome of the second transaction depends on an outcome of the first transaction based at least in part on the list of transactions; and means for suspending execution of the second transaction until after the first transaction is complete based on the determining.
means for maintaining, at a first node of the plurality of nodes, records of a plurality of transactions, each transaction executing on one or more of the plurality of nodes, each record having a transaction state of a plurality of transaction states, the records including a record for a first transaction and a record for a second transaction, execution of the first transaction at a second node of the plurality of nodes including an operation for accessing a first data element stored on the second node and execution of the second transaction at the second node including an operation for accessing the first data element stored on the second node;
means for receiving, at the second node from the first node, a list of transactions that includes any of the plurality of transactions executing on the second node and having a first transaction state at a time of initiation of the second transaction, the list of transactions including the first transaction;
means for determining that an outcome of the second transaction depends on an outcome of the first transaction based at least in part on the list of transactions; and
means for suspending execution of the second transaction until after the first transaction is complete based on the determining.
Ref US20170353309A1: Claims:
A computer system for delegating behavior associated with a contract installed on a blockchain to a non-blockchain application, the computer system comprising: one or more computer-readable storage media storing computer-executable instructions of a cryptodelegate and a cryptlet container service, the cryptodelegate including instructions that receive from code of the contract executing on a virtual machine an identity of a cryptlet and a requested behavior to be performed by the cryptlet, provide to the cryptlet container service the identity and the requested behavior, receive from the cryptlet container service a response generated by the cryptlet performing the requested behavior, and send to the code of the contract the response; and the cryptlet container service including instructions that store information relating to registered cryptlets including references to the cryptlets, receive from the cryptodelegate the identity and the requested behavior, identify a host for executing the cryptlet container and cryptlet, authenticate the cryptlet, provide the requested behavior to the cryptlet, receive the response generated by the cryptlet, and send to the blockchain and verified by cryptodelegate the response; and one or more processors for executing the computer-executable instructions store in the one or more computer-readable storage media.
one or more computer-readable storage media storing computer-executable instructions of a cryptodelegate and a cryptlet container service, the cryptodelegate including instructions that receive from code of the contract executing on a virtual machine an identity of a cryptlet and a requested behavior to be performed by the cryptlet, p
[Truncated to input limit]