Systems and methods for personal identification and verification

Abstract

A personal/client identification and verification process, pseudonymous system and transaction network for monitoring and restricting transactions of cryptography-based electronic money. The present invention—“legal identity-linked credential authentication protocol” is a protocol providing a practical solution for the issues related to cryptocurrency theft, KYC and AML, while maintaining user privacy.

What is claimed is: 
     
         1 . A method for personal/client identification and verification for transactions involving cryptography-based electronic money, the method being executed by a computational server ( 101 ) configured to operate a computer program functioning as a registration interface ( 102 ), and the method being characterized in that it comprises the steps of:
 providing access to one or more potential or existing currency users ( 103 );   providing a registration interface ( 102 ) for one or more potential currency users to register a user account requiring authentication ( 104 );   requesting the submission of documents for proof of the legal identity of a registrant ( 105 );   verifying the legal identity of the registrant ( 106 );   rejecting an account creation for registrants failing in legal identity verification ( 107 );   creating a personal/client account ( 108 ) for individual successful registrants ( 109 ) with successful verification of legal identity ( 110 );   allowing a successful registrant ( 109 ) to create a credential ( 111 ) that comprises an associated authentication ( 112 );   storing ( 116 ) all the submitted information in a client information database ( 115 );   sending ( 117 ) the credential to central approval servers ( 401 ); and   mapping and storing ( 118 ) multisignature currency address(es), credential and legal identity of individual registrants.   
     
     
         2 . The method of  claim 1 , wherein legal identities of owners for individual currency addresses are stored in the client information database. 
     
     
         3 . The methods of  claim 1 , wherein legal identities of owners for individual currency addresses are stored in the client information database, wherein such information is not accessible to the public, in order to maintain the pseudonymous property of the cryptography-based electronic money ( 201 ) and its transaction network ( 202 ). 
     
     
         4 . The methods of  claim 1 , wherein a user can change user's credential ( 111 ) to stop coins being transferred out from a stolen main data file of user's currency wallet ( 301 ). 
     
     
         5 . The methods of  claim 1 , wherein (i) legal identities of owners for individual currency addresses are stored in the client information database, (ii) any currency addresses that are not generated through the submission of a valid credential to one of the central approval servers ( 401 ) are not valid, and are not able to receive any coins, and (iii) only valid registered users have a valid credential ( 112 ). 
     
     
         6 . The method according to  claim 1  characterized in that the authentication is effected by means of a password protection, two factor authentication or multiple factor authentication. 
     
     
         7 . The method according to  claim 1  characterized in that it further comprises a step of encrypting the credentials ( 114 ). 
     
     
         8 . The method according to  claim 1  characterized in that the credential is a digital, electronic or hardware item which can be used as an authentication mechanism to identify oneself, preferably at least one of: unique pair of digital codes, a unique product key for activing a client wallet software, a constantly changing token which is tied to a physical device that is owned by the user, such as a cellphone or a personalized secure key generating device. 
     
     
         9 . A method for creating a cryptography-based electronic money (CBEM) ( 201 ) and its associated transaction network ( 202 ), the method being executed by a network of computer programs functioning as nodes ( 203 ), and the method being characterized in that it comprises the steps of:
 installing a node ( 203 ), which can be a stand-alone computer program or a functional module of a client wallet ( 111 ), in one or more client computers and/or servers ( 204 );   connecting all nodes to form relay nodes of a peer-to-peer network ( 205 ) through a data transmission network ( 206 );   controlling the method for creating at least one unit of the CBEM ( 207 );   protecting the ownerships of at least one unit of the CBEM by public/private-key cryptography ( 208 );   recording ownerships of at least one unit of the CBEM into a ledger ( 209 ) using the owners' currency addresses ( 313 ) ( 210 );   verifying ownerships of at least one unit of the CBEM ( 211 );   restricting only valid registered users ( 109 ) to generate one or more valid currency addresses ( 313 ) to receive at least one unit of the CBEM by verifying the submitted credential ( 111 ) with one of the central approval servers ( 401 ) ( 212 );   recording transactions of at least one unit of the CBEM into the ledger ( 209 ) ( 213 );   verifying transactions of at least one unit of the CBEM ( 214 );   controlling the method for transacting at least one unit of the CBEM ( 215 );   incorporating the transaction rules into the programing code of at least one nodes ( 216 );   restricting at least one transaction approval rule ( 217 ), comprising at least one of: requisition of a valid credential ( 111 ) from the sender, requisition of one or more approval private keys ( 406 ) from one of the central approval servers ( 401 );   allowing only creation of multisignature transactions in pay-to-script-hash format or any other compatible format ( 218 );   allowing only creation of multisignature transactions each requiring at least two private keys as signatures ( 219 );   allowing only creation of multisignature transactions in the presence of a valid credential ( 111 ) ( 220 );   restricting one of these private keys ( 219 ) to be an approval private key ( 406 ) from one of the central approval servers ( 221 );   restricting the rest of the private keys ( 219 ) to be client private keys ( 222 ), which are encrypted and stored in the client wallet(s) ( 301 ) ( 223 );   sending all transaction requests from the client wallets ( 301 ) to one of the central approval servers ( 401 ) to obtain the approval private key for signing the transactions ( 224 ); and   rejecting all transactions missing any one of the required private keys ( 219 ).   
     
     
         10 . The method of  claim 9 , wherein any currency addresses that are not generated through the submission of a valid credential to one of the central approval servers ( 401 ) are not valid, and are not able to receive any coins. 
     
     
         11 . The method of  claim 9 , wherein individual transactions can be monitored with a defined rules to identify, record and report suspicious transactions that is likely to be involved in illegal activities, such as money laundering. 
     
     
         12 . The method of  claim 9 , wherein legal identities of owners of individual currency addresses are stored in the client information database. For those transactions suspected of illegal activities ( claim 11 ), identities of their associated senders and receivers will be extracted from the client information database by tracing with the currency addresses of the senders and receivers. Subsequently, the suspicious activities and the associated client information will be reported to government agencies with respect to the regulations and laws in the associated countries. 
     
     
         13 . The method of  claim 9 , wherein the amount of coins own by a valid registered user are completely and easily traceable and trackable by the central governing body ( 601 ) through analyzing the transaction records in the transactions database ( 413 ). Besides the capability of linking individual currency addresses to their owners, this unique property is contributed by recording unspent coins (if there is any) at the currency address from where the coins have just been sent/spent ( 322 ). This unique property allows applications of our system to financial and banking activities, particularly those required third-party auditing. 
     
     
         14 . A method for personal/client identification and verification for transactions involving cryptography-based electronic money, the method being executed by a computer program functioning as a client device of a user, and the method being characterized in that it comprises the steps of:
 installing a computer program of a client device to function as a client wallet ( 301 ) in at least one computer or computational server ( 302 );   serving as one of the relay nodes ( 205 ) for relaying information of all CBEM units being generated in the transaction network ( 202 ) ( 303 );   serving as one of the relay nodes ( 205 ) for relaying all transaction information in the transaction network ( 202 ) ( 304 );   serving as one of the relay nodes to verify and confirm all transactions that are broadcasted to the transaction network ( 202 ) ( 305 );   generating new coins through contributing to recording any new transaction information into the ledger of all transactions ( 209 ) ( 306 );   generating one or more pairs of cryptographic client public key ( 307 ) and client private key ( 308 ) for receiving and sending coins ( 309 );   storing the client public-private key pairs (items  307 ,  308 ) of one or more currency addresses generated by the currency users ( 310 );   serving as a client wallet for the currency users to receive and send coins; ( 311 );   serving as an client wallet to communicate between one of the central approval servers ( 401 ) and registered currency users ( 109 ) ( 312 );   only generating ( 314 ) currency addresses which are multisignature addresses ( 313 );   generating one of more multisignature addresses ( 313 ) from the client public key ( 307 ) and the approval public key ( 405 ) ( 315 );   only storing one or more multisignature addresses ( 313 ) in the client wallet ( 301 ) for sending and receiving coins ( 316 );   sending one of more multisignature addresses ( 313 ) to the client information database ( 401 ) for storage and mapping to legal identity of the owner of the address(es) ( 317 );   sending the generated valid multisignature addresses ( 313 ) to the central approval servers ( 401 ) for storage ( 318 );   submitting a credential ( 111 ) of a valid registered users ( 109 ) to one of the central approval servers for obtaining approval to generate one or more valid currency multisignature addresses ( 313 ) ( 319 );   submitting a credential ( 111 ) of a valid registered users ( 109 ) to one of the central approval servers for obtaining approval to create one or more valid transactions (items  218 ,  219 ,  220 ,  221 ,  223 ) to send coins to one or more currency addresses ( 320 );   allowing only creation of transactions that use multisignature addresses ( 313 ) for both sending and receiving the coins ( 321 ); and   recording unspent coins (if there is any) into the blockchain at the currency address from where the coins have just been sent ( 322 ).   
     
     
         15 . A method for personal/client identification and verification for transactions involving cryptography-based electronic money, the method being executed by a computer program in a computational server functioning as a central approval server ( 401 ), and the method being characterized in that it comprises the steps of:
 communicating ( 407 ) with a client wallet ( 301 ) to generate one or more valid multisignature currency addresses ( 313 ) in the presence of a valid credential;   providing ( 408 ) approval public key ( 405 ) to the currency wallet to create one or more multisignature addresses ( 313 );   communicating ( 409 ) with the client wallet ( 301 ) to generate one or more valid transactions ( 218 ,  219 ,  220 ,  221 ,  223 ) to send coins to one or more currency address in the presence of a valid credential;   providing ( 410 ) approval private key ( 406 ), which are corresponding to the approval public key ( 405 ) used in creation of the multisignature address ( 313 ), to sign transaction input for one or more valid transactions ( 218 ,  219 ,  220 ,  221 ,  223 );   providing the most recent private key ( 411 ) to sign the whole transaction for one or more valid transactions ( 412 ); and   storing ( 414 ) transaction information in a transactions database ( 413 ).   
     
     
         16 . The method of  claim 15 , wherein the pair of approval public Key ( 405 ) and approval private key ( 406 ) can be changed manually or automatically in a regular period to avoid leakage of the approval public key and the approval private key to the public. After changing to a new pair of approval key, the old approval private key will be used for signing the transaction input ( 410 ), and the new approval private key being used for signing the whole transaction ( 412 ). 
     
     
         17 . The method according to  claim 15 , characterized in that the most recent approval private key ( 411 ) is the approval private key corresponding to the approval public key ( 405 ) used in creation of the multisignature address ( 313 ) or another approval private key. 
     
     
         18 . The method according to  claim 15  characterized in that the step of storing ( 414 ) transaction information in a transactions database ( 413 ) includes storing a transaction ID, sender's currency address, receiver's currency address, amount of coins being transacted, transaction time and IP addresses of the sender and the receiver's client wallets. 
     
     
         19 . The method according to  claim 15 , characterized in that the method further comprises a step of verifying the transaction against one or more transaction criteria ( 501 ,  502 ) at the central approval server ( 401 ). 
     
     
         20 . The method of  claim 19 , wherein the transaction network ( 202 ) can be modified to reject any transactions that do not the meet the central transaction criteria ( 501 ) stored in one of the central approval servers ( 401 ). 
     
     
         21 . The method of  claim 20 , wherein the client transaction criteria ( 502 ) can be defined by a valid registered user to limit his/her own transactions. 
     
     
         22 . The method of  claim 21 , wherein, provide a practical solution for the issues related to cryptocurrency theft, KYC and AML, while maintaining user privacy. 
     
     
         23 . The method of  claim 21 , which can be adopted or modified by the central banks or other financial institutions to issue their own digital currencies that are supported by a distributed ledger payment system, but also regulated by a central governing body. 
     
     
         24 . The method of  claim 20 , wherein the transaction criteria ( 501 ) can be defined by a central governing body ( 601 ) to stop suspicious transactions that is likely to be involved in illegal activities, such as money laundering. 
     
     
         25 . The method according to  claim 15 , characterized in that the one or more transaction criteria ( 501 ,  502 ) include criteria predefined by a central governing body ( 601 ) and/or the registrant. 
     
     
         26 . The method according to  claim 15 , characterized in that the method further comprises a step of tracing legal identities of the sender and receiver by mapping their currency addresses in the transaction database and the client information database when needed. 
     
     
         27 . A method for personal/client identification and verification for transactions involving cryptography-based electronic money, the method being executed by a set of computer programs functioning as devices of a central governing body and a client device of a user, the method being characterized in that it comprises the steps of:
 receiving credentials, of a registrant, comprising at least two factor authentication credentials defining a multisignature;   verifying legal identity of the registrant;   creating a personal/client account ( 108 ) for an individual successful registrant ( 109 ) with successful verification of legal identity ( 110 ) whereas the personal/client account facilitates mapping and storing the multisignature of a currency address and legal identity of individual registrants ( 118 );   providing a registrant wallet comprising at least one unit of electronic money;   recording ownerships of the at least one unit of electronic money into a transactions database ( 413 ) using the registrants' currency address ( 313 );   creating a multisignature transaction, in a pay-to-script-hash format or any other compatible format ( 218 ), each requiring at least two private keys as approval signatures ( 219 );   restricting one of these private keys ( 219 ) to be an approval private key ( 406 ) from one of central approval servers ( 221 );   restricting the rest of the private keys ( 219 ) to be the registrant's private keys ( 222 ), which are stored in the client wallet ( 301 ,  223 );   sending the transaction request from the client wallet ( 301 ) to at least one of the central approval servers ( 401 ) in order to obtain the approval private key for signing the transaction ( 224 ); and   broadcasting the approved transaction messages to all relay nodes in a transaction network ( 214 ).   
     
     
         28 . A system for personal/client identification and verification for transactions involving cryptography-based electronic money, the system comprising:
 a central approval server ( 401 ) configured to execute the method according to  claim 15  in order to process client registration requests, client cryptocurrency addresses, cryptocurrency transactions;   wherein:
 the central approval server ( 401 ) is communicatively coupled to a client information database ( 404 ); 
 the central approval server ( 401 ) is communicatively coupled to a transactions database ( 413 ); and 
 the central approval server ( 401 ) is configured to communicate with at least one client device ( 414 ,  415 ) provided with a registrant wallet ( 416 ,  417 ) comprising at least one unit of electronic money, the at least one client device ( 414 ,  415 ) being configured to execute the method according to  claim 27 . 
   
     
     
         29 . A non-transitory machine-readable storage medium having instructions embodied thereon, the instructions being executable to cause one or more processors to perform all the steps of the computer-implemented method according to one of  claim 1 ,  claim 9 ,  claim 14 ,  claim 15 , or  claim 27 .