US 12,265,965 B2
System and method for preventing suspicious transactions in distributed ledger
Ji Yun Kim, Suwon-si (KR); Jeong Ho Jeon, Seoul (KR); Jong Kwang Kim, Incheon (KR); Hyung Kyu Choi, Seoul (KR); and Hyug Bin Kwon, Seoul (KR)
Assigned to dsrv labs Co., Ltd., Seoul (KR)
Appl. No. 17/790,012
Filed by dsrv labs Co., Ltd., Seoul (KR)
PCT Filed Mar. 26, 2020, PCT No. PCT/KR2020/004086
§ 371(c)(1), (2) Date Jun. 29, 2022,
PCT Pub. No. WO2021/137354, PCT Pub. Date Jul. 8, 2021.
Claims priority of application No. 10-2019-0179106 (KR), filed on Dec. 31, 2019; and application No. 10-2020-0019849 (KR), filed on Feb. 18, 2020.
Prior Publication US 2023/0045098 A1, Feb. 9, 2023
Int. Cl. G06Q 20/40 (2012.01); G06Q 20/36 (2012.01); G06Q 20/38 (2012.01); H04L 9/00 (2022.01); H04L 9/40 (2022.01)
CPC G06Q 20/4016 (2013.01) [G06Q 20/3678 (2013.01); G06Q 20/3825 (2013.01); G06Q 20/3829 (2013.01); G06Q 20/389 (2013.01); H04L 9/50 (2022.05); H04L 63/1441 (2013.01); G06Q 2220/00 (2013.01)] 1 Claim
OG exemplary drawing
 
1. A method for preventing suspicious transactions in a distributed ledger, the method comprising:
step (A) of creating a cryptocurrency wallet storing a cryptocurrency, a public key, and a private key, and setting monitoring-subjected data suspected of being hacked and monitoring-excluded data not suspected of being hacked;
step (B) of checking, by a hacking countermeasure system (20), status of the cryptocurrency wallet, invalidating a hacking transaction by using a hacking countermeasure transaction when the monitoring-subjected data is received and the hacking transaction matching the monitoring-subjected data is received, and allowing the cryptocurrency to be traded and transmitting transaction details when a monitoring-excluded transaction matching the monitoring-excluded data is received; and
step (C) of receiving, by a blockchain network (30), transactions from the hacking countermeasure system (20) to process the transaction details into a block file, and then duplicating the block file into a plurality of block files to distribute and store each block file in a plurality of nodes (31 to 34) sharing each block file,
wherein the step (B) of checking comprises:
receiving and storing the monitoring-subjected data and the monitoring-excluded data;
receiving and storing the private key, or requesting a signature by using the private key, and invalidating a hacking-suspected transaction;
receiving transaction data transmitted from the plurality of nodes (31 to 34);
receiving the monitoring-subjected data and the monitoring-excluded data, and receiving the transaction data, thereby comparing the transaction data with the monitoring-subjected data or the monitoring-excluded data; and
transmitting, to the blockchain network (30), the transaction data or the hacking countermeasure transaction in response to an operation result, and
wherein, when a signature request transaction, which requests transmission of the private key, is received, converting the signature request transaction into a signed transaction by using the private key,
wherein the step (C) of receiving comprises:
receiving transaction details or hacking countermeasure transactions from the hacking countermeasure system (20);
allowing a pending transaction to be included in a new block to be created and then competing to create the block by substituting nonce values in sequence, propagating the block to other nodes, and updating the block in respective electronic ledgers of the nodes after the block is verified passed; and
verifying at each node whether a particular transaction is valid, and then storing the verified particular transaction in a mempool storage, wherein a priority of the verified particular transaction to be stored as the block in the mempool storage is higher for each node by criteria including an order of higher transaction fees.