Office Action 3: Non-Final Rejection (2024-03-19)
Rejection types: 103 - Obviousness, Double Patenting

CLAIMS:
LISTING OF CLAIMS

SVG {EMBED HERE} 0.176.56
1\. (Currently amended) 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 a shared relational database or being in a condition to be synchronized in accordance with the method to be a copy of the shared relational database, the SQL relational database system further comprising a client node, wherein at least one of the plurality of validation nodes is a primary validation node, the primary validation node having received a transaction message comprising instructions to modify data records in the node SQL relational databases of the SQL relational database system,wherein each of the validation nodes stores, in its respective node relational database, a respective blockchain of data blocks, wherein each data block in the blockchain of data blocks comprises at least a cryptographically unambiguous identifier of a previous data block in the respective blockchain of data blocks,wherein each data block further comprises one or more 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 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 tentatively carry out the instructions in the transaction message and later roll back the primary validation node relationalSVG {EMBED HERE} 0.176.56database to the state of the primary validation node relational database present before making 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 first data block in the primary validation node relational database as part of a blockchain of data blocks of the primary validation node,the first data block comprising the transaction message and a cryptographically unambiguous identifier of a data block of the blockchain of data blocks of the primary validation node preceding the first data block;
d) the primary validation node creating a first cryptographically unambiguous identifier of the first data block, and storing the first cryptographically unambiguous identifier in the primary validation node relational database of the primary validation node;and
e) the primary validation node sending a first block message to a first non-primary validation node of the plurality of validation nodes, the firstblock message comprising the firstdata block and thefirst cryptographically unambiguous identifier of the firstdata block;
f) the first non-primary validation node receiving the first block message,
and creating a save point for a first non-primary validation node relational database of the first non-primary validation node, the save point creating a state of the first non-primary validation node relational database to which the first non-primary validation node relational database can be reverted to at a later point in time,so that the first non-primary validation node can tentatively carry out the instructions in the transaction message of the first block message and later roll back the first non-primary validation node relational database to the state of theSVG {EMBED HERE} 0.176.56first non-primary validation node relational database present before making the save point;
g) the first non-primary validation node attempting to carry out the instructions in the transaction message in the firstblock message so as to arrive at a first non-primary validation node relational database that matches the primary validation node relational database and, if the first non-primary validation node is successful in carrying out the instructions in the transaction message in the first block message:h) the first non-primary validation node storing a second data block in the firstnon-primary validation node relational database as part of a blockchain of data blocks of the first non-primary validation node, the second data block comprising the transaction message and a cryptographically unambiguous identifier of a data block of the blockchain of data blocks of the first non-primary validation node preceding the second data block;and \[\[h)\]\]i) the first non-primary validation node creating a second cryptographically unambiguous identifier of the second data block, and storing the second cryptographically unambiguous identifier in the first non-primary validation node relational database;
and \[\[i\]\]i) the primary validation node and the first non-primary validation node removing their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blockchain of data blocks, wherein a determination of whether the plurality of validation nodes have achieved theidentical blockchain of blocks comprises using a consensus algorithm.

2\. (Original) 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 thatSVG {EMBED HERE} 0.176.56enables rollback of a transaction, and releasing that the nested save point if the transaction is carried out successfully.

3\. (Currently amended) The method of claim 1 wherein:the first non-primary validation node checks whether the second cryptographically unambiguous identifier created in step \[\[h)\]\]i) corresponds to the first 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 first non-primary validation node has carried out step \[\[h)\]\]) but not \[\[i)\]\]j), and conditions for sending a second type of commit message \[\[is\]\]are not fulfilled; and
ii. \[\[a\]\]the second type of commit message sent only when the first non-primary validation node has received, from different validation nodes, a predetermined minimal number \[\[P\]\] of commit messages of the first type; and
step \[\[i)\]\]j) 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 the predetermined number of commit messages of the second type is greater than the predetermined minimal number of commit messages of the first type.

4\. (Original) 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\. (Original) The method of claim 3 wherein:SVG {EMBED HERE} 0.176.56each 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\. (Original) The method according to claim 1 where the transaction messages are signed with a digital signature.

7\. (Currently amended) 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\. (Currently amended) The method according to claim 1 where thecryptographicallyunambiguous identifier is a hash.

9\. (Original) 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\. (Currently amended) The method according to claim 1 where the first non- primary validation node ends the procedure and rolls back changes if the transaction message is faulty in step g).

11\. (Currently amended) 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; andSVG {EMBED HERE} 0.176.56a third table comprising a plurality of cryptographically unambiguous identifiers, where each cryptographically unambiguous identifier is acryptographically unambiguous identifier of a data block, wherein each data block comprises at least the cryptographically unambiguous identifier of an immediately previously stored data block and at least one data block comprises at least one transaction message from the second table.

12\. (Currently amended) The method according to claim 11, wherein eachcryptographicallyunambiguous identifier in the third table is logically linked to one or more of the transaction messages in the second table.

13\. (Canceled)

14\. (Currently amended) The relational database system according to claim \[\[13\]\]21, wherein:the first non-primary validation node is operable to check whether the second cryptographically unambiguous identifier created in step \[\[h)\]\]U corresponds to the first cryptographically unambiguous identifier, 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)\]\]j), and conditions for sending a second type of commit message is not fulfilled; and
ii. \[\[a\]\]the second type of commit message sent only when the first non-primary validation node has received, from different validation nodes, a predetermined minimal number \[\[P\]\] of commit messages of the first type; and
step \[\[i\]\])j) comprises a validation node releasing its save point only when a predetermined number \[\[C\]\] of commit messages of the second typeSVG {EMBED HERE} 0.176.56has been received from different validation nodes, and where the predetermined number of commit messages of the second type is greater than the predetermined minimal number of commit messages of the first type.

15\. (Original) 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\. (Canceled)

17\. (Currently amended) The non-transitory computer readable memory according to claim \[\[16\]\]23 further comprising:
the software being executed to cause the first non-primary validation node to check whether the second 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 first 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 conditions for sending a second type of commit message is not fulfilled,
ii. \[\[a\]\]the second type of commit message sent only when the first non-primary validation node has received, from different validationSVG {EMBED HERE} 0.176.56nodes, a predetermined minimal number \[\[P\]\] of commit messages of the first type,
wherein step \[\[i)\]\]j) 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 the predetermined number of commit messages of the second type is greater than the predetermined minimal number of commit messages of the first type.

18\. (Original) 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\. (Currently amended) The non-transitory computer readable memory according to claim \[\[16\]\]23, 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 of a data block, said data block comprising the at least one transaction message and the cryptographically unambiguous identifier of the immediately preceding block of the node; and
comparing the cryptographically unambiguous identifier received in the block message from the primary validation node with the cryptographically unambiguous identifier computed by the node, and, if the cryptographically unambiguous identifiers are the same, to send a commit message to at least one validation node.
SVG {EMBED HERE} 0.176.56
20\. (New) The method of claim 1, further comprising:
the first non-primary validation node sending a second block message to a further non-primary validation node of the plurality of validation nodes, the second block message comprising the second data block and the second cryptographically unambiguous identifier of the second data block,
whereby the further non-primary validation node may receive the second block message and perform steps b) through e) for sending further block messages amongst the remainder of the non-primary validation nodes of the SQL relational database system for replicating the shared relational database across the remainder of the non-primary validation nodes of the SQL relational database system.

SVG {EMBED HERE} 0.176.56
21\. (New) A structured query language (SQL) relational database system comprising:
a memory device;
a processor operatively coupled with the processor; and
a plurality of validation nodes each 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 a shared relational database or being in a condition to be synchronized in accordance with the method to be a copy of the shared relational database, the SQL relational database system further comprising a client node, wherein at least one of the plurality of validation nodes is a primary validation node, the primary validation node having received a transaction message comprising instructions to modify data records in the node SQL relational databases of the SQL relational database system, wherein each of the validation nodes stores, in its respective node relational database, a respective blockchain of data blocks, wherein each data block in the blockchain of data blocks comprises at least a cryptographically unambiguous identifier of a previous data block in the respective blockchain of data blocks, wherein each data block further comprises one or more transaction messages being ordered so that they are executed in a predetermined order, wherein:
a) 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 tentatively 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 making the save point;
b) the primary validation node is operable to attempt to carry out the instructions in the transaction message and, if the attempt to carry out the instructions is successful:
SVG {EMBED HERE} 0.176.56c) the primary validation node is operable to store a first data block in the primary validation node relational database as part of a blockchain of data blocks of the primary validation node, the first data block comprising the transaction message and a cryptographically unambiguous identifier of a data block of the blockchain of data blocks of the primary validation node preceding the first data block;
d) the primary validation node is operable to create a first cryptographically unambiguous identifier of the first data block, and store the first cryptographically unambiguous identifier in the primary validation node relational database of the primary validation node;
and e) the primary validation node is operable to send a first block message to a first non-primary validation node of the plurality of validation nodes, the first block message comprising the first data block and the first cryptographically unambiguous identifier of the first data block;
f) the first non-primary validation node is operable to receive the first block message, and create a save point for a first non-primary validation node relational database of the first non-primary validation node, the save point creating a state of the first non-primary validation node relational database to which the first non- primary validation node relational database can be reverted to at a later point in time, so that the first non-primary validation node can tentatively carry out the instructions in the transaction message of the first block message and later roll back the first non-primary validation node relational database to the state of the first non-primary validation node relational database present before making the save point;
g) the first non-primary validation node is operable to attempt to carry out the instructions in the transaction message in the first block message so as to arrive at a first non-primary validation node relational database that matches the primary validation node relational database and, if the first non-primary validationSVG {EMBED HERE} 0.176.56node is successful in carrying out the instructions in the transaction message in the first block message:
h) the first non-primary validation node is operable to store a second data block in the first non-primary validation node relational database as part of a blockchain of data blocks of the first non- primary validation node, the second data block comprising the transaction message and a cryptographically unambiguous identifier of a data block of the blockchain of data blocks of the first non- primary validation node preceding the second data block; and i) the first non-primary validation node is operable to create a second cryptographically unambiguous identifier of the second data block, and store the second cryptographically unambiguous identifier in the first non-primary validation node relational database; and j) the primary validation node and the first non-primary validation node are operable to remove their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blockchain of data blocks, wherein a determination of whether the plurality of validation nodes have achieved the identical blockchain of blocks comprises using a consensus algorithm.

SVG {EMBED HERE} 0.176.56
22\. (New) The structured query language (SQL) relational database system according to claim 21, wherein the first non-primary validation node is operable to send a second block message to a further non-primary validation node of the plurality of validation nodes, the second block message comprising the second data block and the second cryptographically unambiguous identifier of the second data block,
whereby the further non-primary validation node is operable to receive the second block message and perform steps b) through e) for sending further block messages amongst the remainder of the non-primary validation nodes of the SQL relational database system for replicating the shared relational database across the remainder of the non-primary validation nodes of the SQL relational database system

SVG {EMBED HERE} 0.176.56
23\. (New) A non-transitory computer readable memory storing software thereon that when executed by a computer performs 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 a shared relational database or being in a condition to be synchronized in accordance with the method to be a copy of the shared relational database, the SQL relational database system further comprising a client node, wherein at least one of the plurality of validation nodes is a primary validation node, the primary validation node having received a transaction message comprising instructions to modify data records in the node SQL relational databases of the SQL relational database system, wherein each of the validation nodes stores, in its respective node relational database, a respective blockchain of data blocks, wherein each data block in the blockchain of data blocks comprises at least a cryptographically unambiguous identifier of a previous data block in the respective blockchain of data blocks, wherein each data block further comprises one or more 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 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 tentatively 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 making 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:
SVG {EMBED HERE} 0.176.56c) the primary validation node storing a first data block in the primary validation node relational database as part of a blockchain of data blocks of the primary validation node, the first data block comprising the transaction message and a cryptographically unambiguous identifier of a data block of the blockchain of data blocks of the primary validation node preceding the first data block;
d) the primary validation node creating a first cryptographically unambiguous identifier of the first data block, and storing the first cryptographically unambiguous identifier in the primary validation node relational database of the primary validation node; and e) the primary validation node sending a first block message to a first non-primary validation node of the plurality of validation nodes, the first block message comprising the first data block and the first cryptographically unambiguous identifier of the first data block;
f) the first non-primary validation node receiving the first block message,
and creating a save point for a first non-primary validation node relational database of the first non-primary validation node, the save point creating a state of the first non-primary validation node relational database to which the first non-primary validation node relational database can be reverted to at a later point in time, so that the first non-primary validation node can tentatively carry out the instructions in the transaction message of the first block message and later roll back the first non-primary validation node relational database to the state of the first non-primary validation node relational database present before making the save point;g) the first non-primary validation node attempting to carry out the instructions in the transaction message in the first block message and, if the first non-primary validation node is successful in carrying out the instructions in the transaction message in the first block message:
h) the first non-primary validation node storing a second data block in the first non-primary validation node relational database as part of a blockchain of data blocks of the first non-primary validation
SVG {EMBED HERE} 0.176.56node, the second data block comprising the transaction message and a cryptographically unambiguous identifier of a data block of the blockchain of data blocks of the first non-primary validation node preceding the second data block; and i) the first non-primary validation node creating a second cryptographically unambiguous identifier of the second data block, and storing the second cryptographically unambiguous identifier in the first non-primary validation node relational database; and j) the primary validation node and the first non-primary validation node removing their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blockchain of data blocks, wherein a determination of whether the plurality of validation nodes have achieved the identical blockchain of blocks comprises using a consensus algorithm.

24\. (New) The non-transitory computer readable memory according to claim 23, further comprising:
the first non-primary validation node sending a second block message to a further non-primary validation node of the plurality of validation nodes, the second block message comprising the second data block and the second cryptographically unambiguous identifier of the second data block,
whereby the further non-primary validation node may perform steps b) through e) for sending further block messages amongst the remainder of the non- primary validation nodes of the SQL relational database system for replicating the shared relational database across the remainder of the non-primary validation nodes of the SQL relational database system

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-12,14-15,17-24 are pending in this application
Examiner acknowledges applicant’s amendment filed on 2/20/2024
A request for continued examination under 37 CFR 1.114, including the fee set
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this
application is eligible for continued examination under 37 CFR 1.114, and the fee set
forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on
2/20/2024 has been entered
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.
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.
Instant US application: 17/719,933
US Patent No. 11,334,678
Claim 1,21,23, 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 a shared relational database or being in a condition to be synchronized in accordance with the method to be a copy of the shared relational database the SQL relational database system further comprising a client node, wherein at least one of the plurality of validation nodes is a primary validation node, the primary validation node having received a transaction message comprising instructions to modify data records in the node SQL relational databases of the SQL relational database system wherein at least each of the validation nodes stores, in its respective node relational database, a respective blockchain of data blocks, wherein each data block in the blockchain of data blocks comprises at least a cryptographically unambiguous identifier of a previous data block in the respective blockchain of data blocks, wherein each data block further comprises one or more 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 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 tentatively 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 making 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 first data block in the primary validation node relational database, the first  data block comprising the transaction message and a cryptographically unambiguous identifier of a data block of the blockchain of data blocks of the primary validation node preceding the first data block;
d) the primary validation node creating a first  cryptographically unambiguous identifier of the first data block and storing the first cryptographically unambiguous identifier in the primary validation node relational database of the primary validation node; and ;
e) the primary validation node sending a first block message to a first  non-primary validation node of the plurality of validation nodes, the first block message comprising the first data block and the first cryptographically unambiguous identifier of the first data block;
f) the first non-primary validation node receiving the first block message, and creating a save point for a first non-primary validation node relational database of the first non-primary validation node, the save point creating a state of the first non-primary validation node relational database to which the first non-primary validation node relational database can be reverted to at a later point in time, so that the first non-primary validation node can tentatively carry out the instructions in the transaction message of the first block message and later roll back the first non-primary validation node relational database to the state of the first non-primary validation node relational database present before making the save point;
g) the first non-primary validation node attempting to carry out the instructions in the transaction message in the first block message so as to arrive at a first non-primary validation node relational database that matches the primary validation node relational database and, if first non-primary validation node is successful in carrying out the instructions in the transaction message in the first block message;
h) the first non-primary validation node storing a second data block in the first non-primary validation node relational database as part of a blockchain of data blocks of the first non-primary validation node, the second data block comprising the transaction message and a cryptographically unambiguous identifier of a data block of the blockchain of data blocks of the first non-primary validation node preceding the second data block; and
i)the first non-primary validation node creating a second cryptographically unambiguous identifier of the second data block, and storing the second cryptographically unambiquous identifier in the first non-primary validation node relational database”
j) the primary validation node and the first non-primary validation node removing their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blockchain of data blocks, wherein a determination of whether the plurality of validation nodes have achieved the identical blockchain of blocks comprises using 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 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-12,14-15,17-24 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,21,23.  Omission and/or addition of elements and its function in combination is obvious expedient if the remaining elements perform same functions as before.
Reasons for Allowance
Claims 11-12,14-15,17-24 (re-numbered as 1-22) are allowed.
The following is an examiner’s statement of reasons:
The prior art of Chen et al., US Pub. No. 2018/0219669 is directed to blockchain hash value recomputation, more specifically popularity of hash functions, and their certification by various governmental and other organizations, has led to their widespread usage within blockchains, under the belief that the hash functions are cryptographically secure, further hash functions are periodically proposed and subjected to mathematical scrutiny, resulting in hash functions being developed that are more cryptographically secure than existing hash functions. New blockchains can thus be instantiated that employ better hash functions than existing blockchains (fig 4-5, Abstract, 0011-0012, 0039-0045)
The prior art of Finlow-Bates, US Pub. No. 2018/0084042 is directed to cryptographic keys on a blockchain, more specifically the key announcement message is submitted to the peer-to-peer network, a subset of the plurality of network connected devices associated with the peer-to-peer network may forward copies of the key announcement message to a remainder of the plurality of network connected devices, as is known to those familiar in the art of peer-to-peer network communication. Network connected devices on the peer-to-peer network may be standard nodes, in that they simply forward messages on to other devices on the peer-to-peer network, or they may be enhanced nodes, which are nodes that also perform validation computations on submitted key announcement messages in order to solve a proof-of-work, proof-of-stake or other computationally difficult problem that confirms to other standard nodes and enhanced nodes that the submitted message should be added to the shared ledger (Abstract, 0021-0023, fig 3-4)
The prior art of Sun et al., US Pub. No. 2020/0050595 is directed to data storage layer index for retrieval information, more specifically, efficient searching extensive data storage layers for example blockchain, using consensus algorithm, data elements submitted from the nodes may be collected periodically, e.g., every 10 minutes or roughly a time period needed for solving a block signature code by the blockchain nodes. Further, various nodes may participate in verifying these data elements according to data element verification rules specified by the blockchain protocol 130 (e.g., the data elements are digitally signed, a financial transaction contained in the data element is valid in that the payer has enough balance), to assemble the data elements into a block, to calculate a signature code for the block, and to broadcast the new block to the blockchain system for acceptance. In one implementation, the first node that broadcasts an acceptable block will be responsible for inserting its block into the blockchain. The copies of the blockchain in various nodes are updated with the new block. This particular algorithm for having to solve the signature code, sometimes referred as proof of work is only one example of possible consensus algorithms. Other consensus algorithms, such as “proof of stake”, may be used by the blockchain notes for verifying and creating new data blocks. The insertion of a data element embedded in its data block into the blockchain is alternatively referred to as linking the data element in with the blockchain (Abstract, 0027-0028, fig 6-7)
Under the broadest reasonable interpretation of the claimed limitation which is consistence with the Applicant’s specification.   In view of applicant’s amendment to     the claims, remarks filed on 2/20/2024, Finlow-Bates, US Pub. No. 2018/0084042,         Sun et al., US Pub. No. 2020/0050595   the prior art of Chen et al., US Pub. No. 2018/0219669,  do not disclose, make obvious or otherwise suggest the structure of applicant’s
h) the first non-primary validation node storing a second data block in the first non-primary validation node relational database as part of a blockchain of data blocks of the first non-primary validation node, the second data block comprising the transaction message and a cryptographically unambiguous identifier of a data block of the blockchain of data blocks of the first non-primary validation node preceding the second data block; and
i)the first non-primary validation node creating a second cryptographically unambiguous identifier of the second data block, and storing the second cryptographically unambiquous identifier in the first non-primary validation node relational database”
j) the primary validation node and the first non-primary validation node removing their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blockchain of data blocks, wherein a determination of whether the plurality of validation nodes have achieved the identical blockchain of blocks comprises using consensus algorithm, in claim 1,21,23.
These features, together with the other limitations of the independent           claims are novel and non-obvious over the prior art of record. The dependent        claims  2, 4-8,10,12-13,15-16,18,20 being definite, enabled by the specification,        and further limiting to the independent claims are also allowable.

APPLICANT REBUTTAL: Remarks
The above Amendments and these remarks are in reply to the Office Action having a Notification Date of March 19, 2024 (hereinafter "Office Action").
I.
Request for Interview
In the event the amendments and remarks provided herein fail to place the application in condition for allowance, applicant respectfully requests the opportunity to interview with the Examiner, at the Examiner's convenience and prior to issuance of a subsequent Office Action, to assist in expediting prosecution.
II.
Summary of Re
j
ections
Claims 1-12, 14, 15, and 17-24 were rejected in the Office Action on the grounds of non-statutory double patenting as being unpatentable over claims 1-12 of U.S. Patent No. 11,334,678. Further in the Office Action, claims 1-12, 14, 15, and 17-24 were indicated as being allowed.
Applicant respectfully traverses these rejections.
III.
Summary of Amendment
The amendments herein make only small typographical changes to selected claims, wherein no new matter was added.
Claims 1-12, 14, 15, and 17-24 are pending, wherein claims 1, 21, and 23 are independent.
IV.
The Double Patenting Re
j
ection
In the Office Action, claims 1-19 were rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-12 of U.S. Patent No. 11,334,678.
Without conceding the Examiner's assertion of Obviousness-Type Double Patenting which applicant does not concede and only for purposes of helping to expedite prosecution, a Terminal Disclaimer is being filed herewith.
The Double Patenting rejection should therefore be removed.
Conclusion

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-12,14-15,17-24 are allowed in this application
Examiner acknowledges applicant’s amendment filed on 9/12/2024
A request for continued examination under 37 CFR 1.114, including the fee set
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this
application is eligible for continued examination under 37 CFR 1.114, and the fee set
forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on
2/20/2024 has been entered
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.
Double Patenting
In view of terminal disclaimer approved on 9/12/2024, the double patent rejection is hereby withdrawn.
Reasons for Allowance
Claims 11-12,14-15,17-24 (re-numbered as 1-22) are allowed.
The following is an examiner’s statement of reasons:
The prior art of Chen et al., US Pub. No. 2018/0219669 is directed to blockchain hash value recomputation, more specifically popularity of hash functions, and their certification by various governmental and other organizations, has led to their widespread usage within blockchains, under the belief that the hash functions are cryptographically secure, further hash functions are periodically proposed and subjected to mathematical scrutiny, resulting in hash functions being developed that are more cryptographically secure than existing hash functions. New blockchains can thus be instantiated that employ better hash functions than existing blockchains (fig 4-5, Abstract, 0011-0012, 0039-0045)
The prior art of Finlow-Bates, US Pub. No. 2018/0084042 is directed to cryptographic keys on a blockchain, more specifically the key announcement message is submitted to the peer-to-peer network, a subset of the plurality of network connected devices associated with the peer-to-peer network may forward copies of the key announcement message to a remainder of the plurality of network connected devices, as is known to those familiar in the art of peer-to-peer network communication. Network connected devices on the peer-to-peer network may be standard nodes, in that they simply forward messages on to other devices on the peer-to-peer network, or they may be enhanced nodes, which are nodes that also perform validation computations on submitted key announcement messages in order to solve a proof-of-work, proof-of-stake or other computationally difficult problem that confirms to other standard nodes and enhanced nodes that the submitted message should be added to the shared ledger (Abstract, 0021-0023, fig 3-4)
The prior art of Sun et al., US Pub. No. 2020/0050595 is directed to data storage layer index for retrieval information, more specifically, efficient searching extensive data storage layers for example blockchain, using consensus algorithm, data elements submitted from the nodes may be collected periodically, e.g., every 10 minutes or roughly a time period needed for solving a block signature code by the blockchain nodes. Further, various nodes may participate in verifying these data elements according to data element verification rules specified by the blockchain protocol 130 (e.g., the data elements are digitally signed, a financial transaction contained in the data element is valid in that the payer has enough balance), to assemble the data elements into a block, to calculate a signature code for the block, and to broadcast the new block to the blockchain system for acceptance. In one implementation, the first node that broadcasts an acceptable block will be responsible for inserting its block into the blockchain. The copies of the blockchain in various nodes are updated with the new block. This particular algorithm for having to solve the signature code, sometimes referred as proof of work is only one example of possible consensus algorithms. Other consensus algorithms, such as “proof of stake”, may be used by the blockchain notes for verifying and creating new data blocks. The insertion of a data element embedded in its data block into the blockchain is alternatively referred to as linking the data element in with the blockchain (Abstract, 0027-0028, fig 6-7)
Under the broadest reasonable interpretation of the claimed limitation which is consistence with the Applicant’s specification.   In view of applicant’s amendment to     the claims, remarks filed on 2/20/2024, Finlow-Bates, US Pub. No. 2018/0084042,         Sun et al., US Pub. No. 2020/0050595   the prior art of Chen et al., US Pub. No. 2018/0219669,  do not disclose, make obvious or otherwise suggest the structure of applicant’s
h) the first non-primary validation node storing a second data block in the first non-primary validation node relational database as part of a blockchain of data blocks of the first non-primary validation node, the second data block comprising the transaction message and a cryptographically unambiguous identifier of a data block of the blockchain of data blocks of the first non-primary validation node preceding the second data block; and
i)the first non-primary validation node creating a second cryptographically unambiguous identifier of the second data block, and storing the second cryptographically unambiquous identifier in the first non-primary validation node relational database”
j) the primary validation node and the first non-primary validation node removing their respective save points based on a predetermined number of the plurality of validation nodes having achieved identical blockchain of data blocks, wherein a determination of whether the plurality of validation nodes have achieved the identical blockchain of blocks comprises using consensus algorithm, in claim 1,21,23.
These features, together with the other limitations of the independent           claims are novel and non-obvious over the prior art of record. The dependent        claims  2, 4-8,10,12-13,15-16,18,20 being definite, enabled by the specification,        and further limiting to the independent claims are also allowable.

CITED REFERENCE SUMMARIES: Ref US20180219669A1: Claims:
A non-transitory computer-readable data storage medium storing computer-executable code that a processor executes to: for each block of a plurality of blocks of a blockchain, retrieve data of the block on which basis a first hash value of the block was computed and that is stored in the block; compute, from the retrieved data, a second hash value of the block using a different hash function than a previous hash function by which the first hash value of the block was computed; and add the second hash value to the block within the blockchain.
for each block of a plurality of blocks of a blockchain, retrieve data of the block on which basis a first hash value of the block was computed and that is stored in the block;
compute, from the retrieved data, a second hash value of the block using a different hash function than a previous hash function by which the first hash value of the block was computed; and
add the second hash value to the block within the blockchain.
The non-transitory computer readable data storage medium of claim 1 , wherein the processor executes the computer-executable code to further, for each block of the blockchain except for a first block of the block chain: store, within the block, the second hash value of a previous block to which the block is directly linked within the blockchain, wherein the data of the block on which basis the second hash value of the block is computed includes the second hash value of the previous block.
store, within the block, the second hash value of a previous block to which the block is directly linked within the blockchain,
wherein the data of the block on which basis the second hash value of the block is computed includes the second hash value of the previous block.
The non-transitory computer readable data storage medium of claim 1 , wherein upon computation of the second hash value of each block of the blockchain and addition of the second hash value to the block within the blockchain, any subsequently determined vulnerability of the previous hash function does not compromise data security of the blockchain.
The non-transitory computer readable data storage medium of claim 1 , wherein the processor executes the computer-executable code to further: create a hard fork within the blockchain, wherein new blocks added to the blockchain after creation of the hard fork are generated using the different hash function.
create a hard fork within the blockchain,
wherein new blocks added to the blockchain after creation of the hard fork are generated using the different hash function.
The non-transitory computer-readable data storage medium of claim 4 , wherein the processor executes the computer-executable code to further, after the hard fork has been created: add a new block to the blockchain, including computing a hash value of the block using the different hash function and not the previous hash function.
add a new block to the blockchain, including computing a hash value of the block using the different hash function and not the previous hash function.
The non-transitory computer-readable data storage medium of claim 4 , wherein the previous hash function is not used within the blockchain to compute hash values that are stored within new blocks within the blockchain, after the hard fork has been created.
The non-transitory computer readable data storage medium of claim 1 , wherein the retrieved data of the block includes a plurality of transactions of the block organized as a plurality of hierarchical nodes within a hash tree, and wherein the processor executes the computer-executable code to further: compute the second hash value of the block by, for each transaction, computing a new hash value for the node to which the transaction corresponds, from the transaction, using the different hash function, wherein the processor is to add the second hash value to the block by, for each transaction, adding the new hash value to the node to which the transaction corresponds within the hash tree.
and wherein the processor executes the computer-executable code to further: compute the second hash value of the block by, for each transaction, computing a new hash value for the node to which the transaction corresponds, from the transaction, using the different hash function, wherein the processor is to add the second hash value to the block by, for each transaction, adding the new hash value to the node to which the transaction corresponds within the hash tree.
compute the second hash value of the block by, for each transaction, computing a new hash value for the node to which the transaction corresponds, from the transaction, using the different hash function,
wherein the processor is to add the second hash value to the block by, for each transaction, adding the new hash value to the node to which the transaction corresponds within the hash tree.
The non-transitory computer readable data storage medium of claim 1 , wherein the first hash value of each block that was computed using the previous hash function remains within the block in the blockchain and is not removed or replaced by the second hash value added to the block.
The non-transitory computer readable data storage medium of claim 1 , wherein the blockchain comprises a distributed ledger blockchain.
The non-transitory computer readable data storage medium of claim 9 , wherein the distributed ledger blockchain comprises a public, permissionless distributed ledger blockchain.
The non-transitory computer readable data storage medium of claim 10 , wherein the public, permissionless distributed ledger blockchain comprises the Bitcoin public, permissionless distributed ledger blockchain.
A method comprising: receiving, by a processor of a computing device participating in a blockchain database, one or more transactions; generating, by the processor, a block of the transactions, including computing a hash value for the block using an updated hash function; and chaining, by the processor, the block to a last block of the blockchain database including a plurality of blocks including second hash values computed using the updated hash function and first hash values computed using an original hash function.
receiving, by a processor of a computing device participating in a blockchain database, one or more transactions;
generating, by the processor, a block of the transactions, including computing a hash value for the block using an updated hash function; and
chaining, by the processor, the block to a last block of the blockchain database including a plurality of blocks including second hash values computed using the updated hash function and first hash values computed using an original hash function.
The method of claim 12 , wherein generating the block comprises: generating a hash tree including a plurality of nodes having hash values computed using the updated hash function, based on the transactions.
generating a hash tree including a plurality of nodes having hash values computed using the updated hash function, based on the transactions.
The method of claim 12 , further comprising, prior to generating the block: creating, by the processor, a hard fork within the blockchain database, corresponding to switchover to exclusive usage of the updated hash function for new blocks added to the blockchain database.
creating, by the processor, a hard fork within the blockchain database, corresponding to switchover to exclusive usage of the updated hash function for new blocks added to the blockchain database.
The method of claim 12 , further comprising: transmitting, by the processor, the generated block to a plurality of peer computing devices participating in the blockchain database.
transmitting, by the processor, the generated block to a plurality of peer computing devices participating in the blockchain database.
The method of claim 12 , wherein the blockchain database comprises a public, permissionless distributed ledger blockchain database.
The method of claim 16 , wherein the public distributed ledger blockchain comprises the Bitcoin public, permissionless distributed ledger blockchain database.
A system comprising: a storage device storing a distributed blockchain comprising: a plurality of blocks chained to one another, including temporally earlier blocks that each store both a hash value computed using a prior hash function and a new hash value using an updated hash function, and temporally later blocks that each store just a new hash value computed using the updated hash function; a processor; and a memory storing computer-executable code that the processor executes to validate the distributed blockchain.
a storage device storing a distributed blockchain comprising: a plurality of blocks chained to one another, including temporally earlier blocks that each store both a hash value computed using a prior hash function and a new hash value using an updated hash function, and temporally later blocks that each store just a new hash value computed using the updated hash function;
a plurality of blocks chained to one another, including temporally earlier blocks that each store both a hash value computed using a prior hash function and a new hash value using an updated hash function, and temporally later blocks that each store just a new hash value computed using the updated hash function;
a processor; and
a memory storing computer-executable code that the processor executes to validate the distributed blockchain.
The system of claim 18 , wherein the processor executes the computer-executable code further to assist in maintaining the distributed blockchain, including adding new blocks to the distributed blockchain including just new hash values computed using the updated hash function.
The system of claim 18 , wherein the distributed blockchain comprises the Bitcoin distributed blockchain.
Ref US20180084042A1: Claims:
A method for announcing keys to be used in a shared ledger distributed through a peer-to-peer network comprising: generating, by a network connected device, a key announcement message for a first public key of a first public/private key pair; and transmitting the key announcement message, by the network connected device, through the use of the peer-to-peer network, to a plurality of network connected devices connected to the peer-to-peer network; and appending the key announcement message to the shared ledger stored by the plurality of network connected devices connected to the peer-to-peer network.
generating, by a network connected device, a key announcement message for a first public key of a first public/private key pair; and
transmitting the key announcement message, by the network connected device, through the use of the peer-to-peer network, to a plurality of network connected devices connected to the peer-to-peer network; and
appending the key announcement message to the shared ledger stored by the plurality of network connected devices connected to the peer-to-peer network.
The method of claim 1 , wherein the key announcement message comprises a plurality of public keys of a plurality of public/private key pairs.
The method of claim 2 , further comprising: rejecting, by the plurality of network connected devices, any request to append to the shared ledger a message that references or utilizes a one or more of the plurality of public keys of the plurality of public/private key pairs before the key announcement message for the one or more of the plurality of public keys has been included in the shared ledger by the plurality of network connected devices.
rejecting, by the plurality of network connected devices, any request to append to the shared ledger a message that references or utilizes a one or more of the plurality of public keys of the plurality of public/private key pairs before the key announcement message for the one or more of the plurality of public keys has been included in the shared ledger by the plurality of network connected devices.
The method of claim 2 , wherein the key announcement message is signed using a second one of the plurality of private keys of the plurality of public/private key pairs.
The method of claim 2 , wherein the key announcement message is signed using a private key associated with a public key announced in an earlier key announcement message on the shared ledger.
The method of claim 2 , wherein the key announcement message is signed using a private key associated with a public key announced in a first block of the shared ledger.
The method of claim 2 , further comprising: performing a validation computation on the key announcement message by a first one of the plurality of network connected devices, the first one of the plurality of network connected devices being connected to the peer-to-peer network; and transmitting the key announcement message and a result of the validation computation by the first one of the plurality of network connected devices through a peer-to-peer network, to a remainder of the plurality of network connected devices connected to the peer-to-peer network; and appending to the shared ledger stored by the plurality of network connected devices connected to the peer-to-peer network, the key announcement message and the result of the validation computation.
performing a validation computation on the key announcement message by a first one of the plurality of network connected devices, the first one of the plurality of network connected devices being connected to the peer-to-peer network; and
transmitting the key announcement message and a result of the validation computation by the first one of the plurality of network connected devices through a peer-to-peer network, to a remainder of the plurality of network connected devices connected to the peer-to-peer network; and
appending to the shared ledger stored by the plurality of network connected devices connected to the peer-to-peer network, the key announcement message and the result of the validation computation.
The method of claim 7 , further comprising: producing the result of the validation computation by the first of the plurality of network connected devices before any of the remainder of the plurality of network connected devices connected to the peer-to-peer network can produce said result of the validation computation; and creating a record of a number of commercially-valued credits associated with a second public key of a second private/public key pair associated with the first of the plurality of network connected devices; and including the record of the number of commercially-valued credits in the shared ledger with the result of the validation computation and the key announcement message in the shared ledger stored by the plurality of network connected devices.
producing the result of the validation computation by the first of the plurality of network connected devices before any of the remainder of the plurality of network connected devices connected to the peer-to-peer network can produce said result of the validation computation; and
creating a record of a number of commercially-valued credits associated with a second public key of a second private/public key pair associated with the first of the plurality of network connected devices; and
including the record of the number of commercially-valued credits in the shared ledger with the result of the validation computation and the key announcement message in the shared ledger stored by the plurality of network connected devices.
The method of claim 8 , further comprising: including in the key announcement message, an offering of a number of commercially-valued credits associated with a third public key and recorded on the shared ledger, by the network connected device; and transferring said number of commercially-valued credits to the second public key of the second public/private key pair associated with the first of the plurality of network connected devices when including the key announcement message in the shared ledger.
including in the key announcement message, an offering of a number of commercially-valued credits associated with a third public key and recorded on the shared ledger, by the network connected device; and
transferring said number of commercially-valued credits to the second public key of the second public/private key pair associated with the first of the plurality of network connected devices when including the key announcement message in the shared ledger.
The method of claim 8 , further comprising: associating the commercially-valued credits with one or more of: a network address, a cryptographic key, an email address, a device MAC address, a telephone number, a username.
associating the commercially-valued credits with one or more of: a network address, a cryptographic key, an email address, a device MAC address, a telephone number, a username.
A plurality of network connected devices, each comprising: one or more processors, and storage media comprising computer instructions, said plurality of network connected devices being connectible via a peer-to peer network to each other, arranged such that when computer instructions are executed on the one or more processors of a one or more of the plurality of network connected devices, operations are caused comprising: generating, by a first of the plurality of network connected devices, a key announcement message for a first public key of a first public/private key pair; and transmitting the key announcement message, by the first of the plurality of network connected devices, through the use of the peer-to-peer network, to a remainder of the plurality of network connected devices connected to the peer-to-peer network; and appending the key announcement message, by the plurality of network connected devices, to the shared ledger stored by the plurality of network connected devices connected to the peer-to-peer network.
generating, by a first of the plurality of network connected devices, a key announcement message for a first public key of a first public/private key pair; and
transmitting the key announcement message, by the first of the plurality of network connected devices, through the use of the peer-to-peer network, to a remainder of the plurality of network connected devices connected to the peer-to-peer network; and
appending the key announcement message, by the plurality of network connected devices, to the shared ledger stored by the plurality of network connected devices connected to the peer-to-peer network.
The plurality of network connected devices of claim 11 , wherein the key announcement message generated by the first of the plurality of network connected devices comprises a plurality of public keys for a plurality of public/private key pairs.
The plurality of network connected devices of claim 12 , further comprising: rejecting, by a second remainder of the plurality of network connected devices, any request by a second network connected device to append to the shared ledger a message that references or utilizes a one of the plurality of public keys of the plurality of public/private key pairs before a key announcement message for the one of the plurality of public keys has been submitted to the peer-to-peer network by the first of the plurality of network connected devices and is included in the shared ledger by the remainder of the plurality of network connected devices.
rejecting, by a second remainder of the plurality of network connected devices, any request by a second network connected device to append to the shared ledger a message that references or utilizes a one of the plurality of public keys of the plurality of public/private key pairs before a key announcement message for the one of the plurality of public keys has been submitted to the peer-to-peer network by the first of the plurality of network connected devices and is included in the shared ledger by the remainder of the plurality of network connected devices.
T
[Truncated to input limit]