A multi-confirmation system that uses M keys out of N to restore customer wallets.

Abstract

We provide computing systems and methods for communicating with customer devices and trusted third parties. [Solution] In the currency conversion system, the network interface receives customer identity data and a request to restore the customer wallet from the customer device. The processor verifies the customer identity data received from the customer device. Once the processor has verified the customer identity data received from the customer device, the network interface communicates a request to a trusted third-party key repository for a first key associated with the customer wallet. The processor uses the first key associated with the customer wallet and a second key associated with the customer wallet to restore the customer wallet.

Description

Technical Field

[0001] Cross - reference to related applications

[0001] This application claims priority to U.S. Provisional Patent Application No. 62 / 618,077, filed on January 17, 2018, entitled "MULTI - SIGNATURE (MULTI - SIG) WITH THREE KEYS REQUIRING TWO OF THREE KEYS TO ACCESS CRYPTOCURRENCY WALLET AND STORING KEYS WITH USER, TRUSTED 3RD PARTY, AND EXCHANGE", and U.S. Provisional Patent Application No. 62 / 663,921, filed on April 27, 2018, entitled "MULTI - APPROVAL CRYPTOCURRENCY SYSTEM REQUIRING M OF N KEYS TO ACCESS AND RESTORE CRYPTOCURRENCY WALLET", and U.S. Provisional Patent Application No. 62 / 663,922, filed on April 27, 2018, entitled "MULTI - APPROVAL CRYPTOCURRENCY SYSTEM REQUIRING M OF N KEYS TO ACCESS AND RESTORE CRYPTOCURRENCY WALLET(暗号通貨ウォレットにアクセスして復元するために、N個のうちM個の鍵を必要とするマルチ承認暗号通貨システム)」と題された米国特許仮出願第62 / 663,922号(代理人整理番号270.018USP2)。 (注:原文中最后一段的英文内容不完整,推测应该是“CRYPTOCURRENCY WALLET”,所以翻译时补充完整了这段英文内容。)We claim the interests of U.S. Patent Provisional Application No. 62 / 663,922 (Agent No. 270.019USPR) titled "CRYPTOCURRENCY WALLET (A Multi-Approval Cryptocurrency System Requiring M of N Keys to Access and Restore a Cryptocurrency Wallet)" and U.S. Patent Provisional Application No. 62 / 780,779 (Agent No. 270.027USPR) filed on 17 December 2018, titled "MULTI-APPROVAL CRYPTOCURRENCY SYSTEM," all of which are incorporated herein by reference.

[0002]

[0002] This application relates to the following concurrently pending U.S. patent applications, which are incorporated herein by reference.

[0003]

[0003] U.S. Patent Application No. __________ (Agent Reference Number 270.019US01), filed on the same day as this application and incorporated herein by reference, “MULTI-APPROVAL SYSTEM USING M OF N KEYS TO GENERATE A TRANSACTION ADDRESS”.

[0004]

[0004] U.S. Patent Application No. __________ (Agent Reference Number 270.027US01), filed on the same day as this application and incorporated herein by reference, “MULTI-APPROVAL SYSTEM USING M OF N KEYS TO PERFORM AN ACTION AT A CUSTOMER DEVICE”.

[0005]

[0005] Titled "MULTI-APPROVAL SYSTEM USING M OF N KEYS TO GENERATE A SWEEPING TRANSACTION AT A CUSTOMER DEVICE" And, U.S. Patent Application No. __________ (Agent Reference Number 270.029US01), filed on the same day as this application and incorporated herein by reference. [Background technology]

[0006]

[0006] Encryption can be used to securely store and transmit data. Keys can be used to encrypt data and to decrypt encrypted data. [Overview of the Initiative]

[0007]

[0007] A computing system is disclosed which includes at least one processor and at least one memory communicatively coupled to the at least one processor. The computing system also includes at least one network interface communicatively coupled to the at least one processor and configured to communicate with a customer device and a trusted third party. The at least one network interface is configured to receive from the customer device customer identity data and a request to restore the customer wallet. The at least one processor is configured to verify the customer identity data received from the customer device. Once the at least one processor has verified the customer identity data received from the customer device, the at least one network interface is configured to communicate a request to a trusted third-party key repository for a first key associated with the customer wallet. The at least one processor is configured to restore the customer wallet using the first key associated with the customer wallet and a second key associated with the customer wallet.

[0008]

[0008] Understanding that the drawings only show exemplary embodiments and should not be considered limiting in scope, the exemplary embodiments are described with additional specificity and detail through the use of the accompanying drawings. [Brief explanation of the drawing]

[0009] [Figure 1] This block diagram shows an exemplary system for multi-confirmation cryptocurrency accounts and transactions. [Figure 2A] This block diagram shows an exemplary node tree on a customer device for implementing a customer wallet. [Figure 2B] This block diagram shows another exemplary node tree on a currency conversion system for implementing customer wallets. [Figure 2C] This block shows another exemplary node tree on a trusted third party for implementing a customer wallet. [Figure 3] This flowchart illustrates an exemplary method for onboarding customers in a multi-approval system. [Figure 4] This flowchart illustrates an exemplary method for purchasing cryptocurrency in a multi-consensus system. [Figure 5] This block diagram shows an exemplary currency conversion system for generating multi-approval transaction addresses. [Figure 6] This is a flowchart illustrating a method for generating a multi-approval transaction address. [Figure 7A] This flowchart illustrates an exemplary method for cryptocurrency transactions in a multi-confirmation system. [Figure 7B] This flowchart illustrates an exemplary method for cryptocurrency transactions in a key-splitting system. [Figure 8A] This flowchart illustrates a first exemplary method for signing transaction requests using multisig. [Figure 8B] A flowchart showing a second exemplary method for signing a transaction request using multi-signature. [Figure 8C] A flowchart showing a third exemplary method for signing a transaction request using multi-signature. [Figure 8D] A flowchart showing a fourth exemplary method for signing a transaction request using multi-signature. [Figure 8E] A flowchart showing an exemplary method for signing a transaction request using key splitting. [Figure 9A] A flowchart showing an exemplary method for restoring a customer wallet after the loss of the customer's private key using multi-signature. [Figure 9B] A flowchart showing another exemplary method for restoring a customer wallet after the loss of the customer's private key using multi-signature. [Figure 9C] A flowchart showing an exemplary method for restoring a customer wallet after the loss of a customer's private key component using key splitting. [Figure 10A] A block diagram showing an exemplary method for restoring a customer wallet using multi-signature. [Figure 10B] A block diagram showing another exemplary method for restoring a customer wallet using multi-signature. [Figure 10C] A block diagram showing an exemplary method for restoring a customer wallet using key splitting. [Figure 11] A block diagram showing an exemplary system for transacting from a multi-approved transaction address. [Figure 12] A block diagram showing another exemplary system for multi-approved cryptocurrency accounts and transactions. [Figure 13] A flowchart showing an exemplary method for performing an action based on at least M out of N private keys (or key components). [Figure 14]FIG. is a flowchart showing an exemplary method for encrypting or decrypting data based on at least M secret keys (or key components) out of N secret keys. [Figure 15] FIG. is a flowchart showing an exemplary method for generating a transaction address on a customer device. [Figure 16A] FIG. is a flowchart showing an exemplary method for signing a transaction using at least M secret keys (or key components) out of N secret keys. [Figure 16B] FIG. is a flowchart showing an exemplary method for signing a transaction using at least M secret keys (or key components) out of N secret keys. [Figure 16C] FIG. is a flowchart showing an exemplary method for signing a sweep transaction using at least M secret keys (or key components) out of N secret keys on a customer device. [Figure 17] FIG. is a block diagram showing an exemplary computer system that can utilize some embodiments of the present disclosure. [Figure 18] FIG. is a block diagram showing another exemplary computing device. DETAILED DESCRIPTION OF THE INVENTION

[0010]

[0040] In accordance with common practice, the various features described are not drawn to scale and are drawn to emphasize specific features relevant to the exemplary embodiments.

[0011]

[0041] In the following detailed description, reference is made to the accompanying drawings, which form a part hereof and show, by way of illustration, specific exemplary embodiments. However, it is to be understood that other embodiments may be utilized and logical, mechanical, and electrical changes may be made. Further, the methods presented in the drawings and the specification are not to be construed as limiting the order in which the individual steps may be performed. Accordingly, the following detailed description is to be construed in a non-limiting sense It shouldn't be done.

[0012]

[0042] Keys, including cryptographic keys, can be used to encrypt data, decrypt data, and sign transactions. Keys can include (but are not limited to) private keys, public keys, cryptographic keys, signing keys, other cryptographic keys, and passwords and secrets. One challenge with keys is keeping them secure and accessible when needed. In some cases, restricting access to a wallet to a single person / entity is undesirable, as it could leave the wallet vulnerable to malicious attacks. Instead, it may be desirable to require verification by multiple people / entities to use the wallet.

[0013]

[0043] Multiple private keys can be used in multi-signature (multisig) scenarios where M / N (e.g., 2 / 3) keys are required to use or restore a wallet. Distributing keys across different devices reduces the possibility of unauthorized users accessing the wallet. In the example, three private keys are generated and distributed across various devices in a multisig system: (1) a first key held by the customer (end user), (2) a second key held by the currency conversion system (e.g., a money services business (MSB)) or exchange, and (3) a third key held by a trusted third party (such as a credit union or bank).

[0014]

[0044] Instead of multisig, a key can be split into multiple key components (i.e., parts), and a subset of these key components can be used to reconstruct the key, i.e., key splitting. In the example, a specific number of key components may be needed to reconstruct a particular key. For example, a particular key can be split into N key components, and M of these N components (e.g., 2 / 3) are needed to reconstruct the particular key. In the example, the N key components can be distributed to various users, for example, (1) a first key component held by a customer (end user), (2) a second key component held by a currency conversion system (e.g., a money services business (MSB)) or exchange, and (3) a third key component held by a trusted third party (e.g., a credit union or bank). In the example, the key is split into sets of key components by at least one of polynomial interpolation or Shamir secret sharing.

[0015]

[0045] In the example, keys and / or key components may be distributed electronically to a device by polling (or pulling) notifications, or by Bluetooth, Wi-Fi, or Near Field Communication (NFC) transmission, using at least one of email, short message service (SMS), multimedia messaging service (MMS), instant messaging, or push notifications (such as push confirmation notifications). In the example, keys and / or key components may be displayed on a screen, written down, physically distributed (as Quick Response (QR) codes, barcodes, etc.) through printing, or stored on a USB key / memory stick (or other solid-state drive), or on an optical or magnetic disk. Furthermore, an index of a key or key component in a node tree may be communicated from a first device to a second device, and a key or key component may be derived from a different key already stored in the second device.

[0016]

[0046] Under normal operation, private keys from both the customer (end-user) and the currency conversion system / exchange may be required to conduct transactions from the customer's wallet, for example, to transfer cryptocurrency from a transaction address. If the user loses their private key (for example, if the device containing the private key is lost, destroyed, or upgraded), the currency conversion system / exchange and trusted third parties (credit unions or banks) may need to obtain private keys. The private keys of (etc.) may be used to restore the wallet. Once the wallet is restored, new private keys (or private key components) may be generated for (1) the customer (end user), (2) the currency conversion system / exchange, and (3) a trusted third party (such as a credit union or bank).

[0017]

[0047] Figure 1 is a block diagram showing an exemplary system 100 for multi-confirmation cryptocurrency accounts and transactions. System 100 may include a customer device 102, a currency conversion system 104, a trusted third party 106, an optional asset exchange 108, an optional identity service provider 110, and a distributed ledger 118. Furthermore, system 100 may include two or more of each device.

[0018]

[0048] Each of the customer device 102, currency conversion system 104, trusted third party 106, asset exchange 108, and identity service provider 110 may be implemented as a mobile computing device such as a mobile phone, tablet computer, mobile media device, mobile gaming device, laptop computer, or vehicle-based computer, or as a non-mobile computing device such as a dedicated terminal, public terminal, kiosk, server, cloud server, or desktop computer.

[0019]

[0049] In the example, each of the customer device 102, the currency conversion system 104, and the trusted third party 106 may include at least one memory, at least one processor, at least one optional network interface, at least one optional display device, at least one optional input device, and at least one optional power supply. Furthermore, each of the customer device 102, the currency conversion system 104, and / or the trusted third party 106 may be implemented using multiple physical devices.

[0020]

[0050] System 100 can use a multi-affirmation methodology, such as a multi-party multi-signature (multisig) methodology, a multi-party key splitting methodology, or a combination of the two. The multi-party multi-signature (multisig) methodology can distribute different private keys (e.g., unique strings of numbers, letters, and / or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multisig, a cryptocurrency purchase or transaction requested by a customer must be signed using M / N (e.g., 2 out of 3) private keys, for example, by the customer device 102 and the currency conversion system 104. The private keys can be generated by the customer device 102, the currency conversion system 104, the trusted third party 106, or a combination of these. The multisig methodology does not require the splitting of private keys.

[0021]

[0051] Alternatively, system 100 may use a multi-party key splitting methodology in which a private key (e.g., a unique string of numbers, letters, and / or other characters) is split into three (or any appropriate number) key components. In the example, the key components can be generated using polynomial interpolation or Shamir secret sharing. In the multi-party key splitting methodology, different key components may be placed in each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using the multi-party key splitting methodology, a cryptocurrency purchase or transaction requested by a customer needs to be signed using M out of N key components (e.g., 2 / 3 of the key components) so that it is signed, for example, by the customer device 102 and the currency conversion system 104. The private key can be reconstructed in the customer device 102, the currency conversion system 104, or the trusted third party 106.

[0022]

[0052] The configurations disclosed herein using a multisignature methodology (i.e., signing transaction requests or purchase requests with an M / N private key) may instead use key splitting (i.e., reconstructing the private key with the M / N private key components and then using the private key to sign transaction requests or purchase requests).

[0023]

[0053] Alternatively, system 100 may use a combination of multi-party multisig and key splitting methodologies, where the first private key is split into two key components, with different key components placed on the customer device 102 and the currency conversion system 104, respectively. The (unsplit) second private key may be placed on a trusted third party 106. Using this combination, any cryptocurrency purchase or transaction requested by the customer must be signed using either the second private key or both key components of the first private key.

[0024]

[0054] As used herein, the term “signature” or its variation means adding or modifying data associated with a desired transaction using a key (or key component). For example, signing a transaction may involve using an M / N (e.g., 2 / 3) private key to encrypt or transform a transaction address. Furthermore, a public key may be derived from a corresponding private key (or parent public key), and a public key may be used for deriving a transaction address, monitoring transactions at a transaction address, and / or displaying an account balance (e.g., on a blockchain). However, a public key cannot be used for transactions from a transaction address; that is, a public key cannot be used to sign a transaction. Rather, a device may use one or more private keys (or private key components) to execute a transaction from a transaction address.

[0025]

[0055] As used herein, unless otherwise specified, the term “customer” (or “user”) means a person (or automated instruction, e.g., a script) that accesses customer device 102 to initiate any of the functions described herein, such as creating a multisig account, purchasing multisig cryptocurrency, performing a multisig transaction using cryptocurrency, or restoring a multisig account.

[0026]

[0056] As used herein, the term “wallet” refers to a software program, digital file, and / or memory used to store and / or manage digital assets such as cryptocurrencies. While the systems and methods described herein use cryptocurrencies, they are also compatible with any type of digital asset. In the examples, a wallet is defined by one or more private keys, one or more public keys derived from one or more private keys, and / or one or more transaction addresses derived from one or more private keys and / or one or more public keys. In the examples, a wallet may be defined by one or more private account keys (and, optionally, corresponding public account keys), each of which may have one or more child and / or grandchild transaction keys.

[0027]

[0057] As used herein, the term “distributed ledger” refers to an electronic ledger distributed across multiple interconnected nodes, where two or more nodes store copies of the ledger. In the example, distributed ledger 118 may implement one or more blockchains to verify the data stored within distributed ledger 118. A blockchain is a verifiable, persistent ledger that builds one block at a time, with each block that verifies the block bearing a proof-of-work seal (such as a hash). In a blockchain, the hash of the previous block is included in the current block, so by recursion, The current hash verifies all previous blocks and returns to the original genesis block. When a hash is inserted into the blockchain, it is permanently recorded and acts as a notary public verifying the existence of the timestamped hash data when that block is added to the chain. Future blocks add a layer of protection against manipulation of data stored in the chain and reorganization of the chain, adding certainty that no changes can be made to earlier blocks in the chain. A blockchain is an implementation of a distributed ledger, which can be public (i.e., publicly viewable) or secret. Exemplary blockchains include, but are not limited to, the Bitcoin blockchain, the Ethereum blockchain, BigchainDB, Billion, Chain, Corda, Credits, Elements, Monax, Fabric, HydraChain, Hyperledger, Multichain, Openchain, Quorum, Sawtooth, and Stellar.

[0028]

[0058] In this example, customer device 102 may be a mobile device using, for example, the Android® or iOS® operating system. The customer can download an application corresponding to the currency conversion system 104 to customer device 102. The application can present a user interface on customer device 102, and the customer can provide input using the user interface. Based at least in part on user input, the application on customer device 102 can send and receive commands and / or other data to and from the currency conversion system 104. In this example, the application on customer device 102 can only communicate directly with the currency conversion system 104, which communicates with other devices in system 100; that is, the currency conversion system 104 can be a gateway to other devices in system 100. Alternatively, the application on customer device 102 can communicate directly with a trusted third party 106, the currency conversion system 104, and / or other devices within system 100.

[0029]

[0059] The currency conversion system 104 may be a bank or non-bank financial institution that converts currency into other forms of currency, such as money services business (MSB). In this example, the currency conversion system 104 may be implemented on one or more servers. The currency conversion system 104 may maintain a key repository 114 for storing keys (e.g., in a database and / or secure memory) associated with one or more customer wallets. The key repository 114 may be physically located on the same or different devices that perform other functions of the currency conversion system 104. The currency conversion system 104 may or may not have a remittance license required under applicable rules and regulations.

[0030]

[0060] In the example, the currency conversion system 104 can assist end users (i.e., customers) when purchasing cryptocurrencies such as Bitcoin. Specifically, the currency conversion system 104 enables customers to convert currency to other forms of currency, for example, fiat currency to cryptocurrency (e.g., Bitcoin), cryptocurrency (e.g., Bitcoin) to fiat currency, one type of cryptocurrency (e.g., Bitcoin) to another form of currency (e.g., Ethereum), etc. In the example, the currency conversion system 104 may also enable customers to conduct transactions using cryptocurrency, i.e., to buy and / or sell goods and / or services in exchange for cryptocurrency. In addition to cryptocurrency, the currency conversion system 104 may also enable other types of assets, for example, at least one security, at least one bond, at least one commodity, at least one real estate, at least one item of personal assets, at least one fund, at least one currency fund, at least one listed fund, at least one mutual fund, at least one index fund, at least one bond fund, at least one commodity fund A real estate fund, or at least one such fund, can be used to enable purchases and / or transactions.

[0031]

[0061] To enable the purchase of cryptocurrencies and transactions using cryptocurrencies, the currency conversion system 104 can communicate with an asset exchange 108. The asset exchange 108 may be a market (and / or an entity operating a market) where securities, commodities, derivatives and / or other financial instruments, such as Kraken, SFOX, Coinbase®, etc., are traded. In this example, the asset exchange 108 may serve as a market for cryptocurrencies, digital currencies, fiat currencies and / or commodity currencies. In this example, the asset exchange 108 described herein may record transactions that have been successfully executed on a distributed ledger 118, such as a blockchain. Alternatively, or in addition, the asset exchange 108 may be configured to trade at least one security, at least one bond, at least one commodity, at least one real estate, at least one personal asset, at least one fund, at least one currency fund, at least one listed fund, at least one mutual fund, at least one index fund, at least one bond fund, at least one commodity fund, or at least one real estate fund. The asset exchange 108 may be implemented using one or more computing devices.

[0032]

[0062] The trusted third party 106 may be a financial institution. In the example, the trusted third party 106 may be implemented using one or more trusted computing devices that are trusted to verify transactions between two parties. In the example, the trusted third party 106 may be owned and operated by a credit union or a bank. The trusted third party 106 may receive information from the currency conversion system 104 about a transaction requested by the customer device 102. Alternatively, the trusted third party 106 may receive information about the requested transaction directly from the customer device 102. In either case, the information received by the trusted third party 106 may indicate that the pending transaction needs to be signed (e.g., authenticated) using a private key stored in the trusted third party 106. The trusted third party 106 may also communicate with an identity service provider 110, for example, during the process of creating a customer account. The trusted third party 106 may maintain a key repository 116 for storing keys (e.g., databases and / or secure memory) associated with one or more customer wallets. The key repository 116 may be physically located on the same or different devices that perform other functions of the trusted third party 106. In the example, keys (or key components) stored in the key repository 116 for a trusted third party 106 may only be used in emergencies, such as when a customer device 102 (and any keys stored therein) is lost, destroyed, upgraded, or hard-reset / reformatted. In the example, the trusted third party 106 may have the necessary remittance licenses under applicable rules and regulations.

[0033]

[0063] Identity service provider 110 may be one or more computing devices that provide anti-money laundering (AML) and / or customer verification (KYC) services. AML services may include one or more steps to verify that a potential (or current) customer is not in violation of relevant laws designed to combat money laundering. In other words, AML services require that the potential (or current) customer ensure that they have not taken any measures to conceal sources of funds received from illegal or unethical activities. KYC services may include collecting and verifying information about the identity and / or financial transactions of a potential (or current) customer. AML and KYC may include one or more steps for monitoring. For example, KYC services may include collecting basic identity data (e.g., name, contact information), verifying that the customer is who they claim to be, and / or verifying that the customer is not on any law enforcement watchlists. KYC services may also include performing soft credit checks (e.g., based on the customer's basic identity data), analyzing the customer's transactional behavior, and / or monitoring the customer's account for fraud based on the customer's transactional behavior. AML and KYC may be required under various federal, state, and / or local laws.

[0034]

[0064] Each device in system 100 may be communicably coupled to one or more other devices using at least one network 112 (e.g., networks 112A-B). In the example, at least one network 112 includes at least one wired network and / or at least one wireless network. In the example, any combination of wired and wireless networks can be used to couple the customer device 102, the currency conversion system 104, and the trusted third party 106. In the example, at least one network 112 includes at least one of at least one local area network (LAN), at least one wide area network (WAN), or the internet. In the example, any combination of local area networks, wide area networks, or the internet can be used as at least one network 112 to couple the customer device 102, the currency conversion system 104, and the trusted third party 106.

[0035]

[0065] Devices within system 100 enable customers to purchase cryptocurrency and conduct transactions using cryptocurrency with multi-confirmation security. In the multi-signature example, the currency conversion system 104 and / or a trusted third party 106 can create a separate multi-signature account for the customer (for multi-signature cryptocurrency transactions), i.e., "onboard" the customer. In the example, one or more devices within system 100 can also operate to make a purchase of multi-signature cryptocurrency and store the cryptocurrency in the customer wallet. In the example, one or more devices within system 100 can also operate to execute a multi-signature cryptocurrency transaction, for example, to purchase goods or services in exchange for cryptocurrency. In the example, one or more devices within system 100 can also operate to restore the customer account with multiple keys after, for example, the customer device 102 is lost, damaged, upgraded, or hard reset / reformatted.

[0036]

[0066] In the key splitting example, the currency conversion system 104 and / or a trusted third party 106 can create separate split-key accounts (for cryptocurrency transactions using split-key components) for each customer (i.e., customer "onboarding"). In the example, one or more devices within system 100 can also operate to make cryptocurrency purchases (using multiple key components) and store the cryptocurrency in a customer wallet. In the example, one or more devices within system 100 can also operate to perform cryptocurrency transactions that require multiple key components, for example, purchasing goods or services in exchange for cryptocurrency. In the example, one or more devices within system 100 can also operate to restore a customer account using multiple key components, for example, after a customer device 102 is lost, damaged, upgraded, or hard-reset / reformatted.

[0037]

[0067] Figure 2A shows an exemplary node on customer device 102 for implementing a customer wallet. This is a block diagram of node tree 200A. In this example, node tree 200A can implement a hierarchical deterministic (HD) wallet for customers in accordance with parts of Bitcoin Improvement Proposal 32 (BIP32) and / or parts of Bitcoin Improvement Proposal 44 (BIP44). BIP32 (available at https: / / github.com / bitcoin / bips / blob / master / bip-0032.mediawiki) and BIP44 (available at https: / / github.com / bitcoin / bips / blob / master / bip-0044.mediawiki) are incorporated herein by reference.

[0038]

[0068] The node tree 200A may reside on the customer device 102 and may include hierarchical levels. Specifically, the node tree 200A may include a private account key 204 and a public account key 205 at the first level (L1). The private account key 204 may be a unique string of numbers, letters, and / or other characters specific to the customer. The private account key 204 may also be specific to the type of cryptocurrency; for example, the customer device 102 may contain a different private account key 204 for each type of cryptocurrency stored in the customer wallet. In the example, the customer device 102 may store separate private account keys 204 for each of Bitcoin, Ethereum, Litecoin, etc. A customer wallet may be defined by the private account key 204 and / or other private account keys (not shown).

[0039]

[0069] Optionally, the private account key 204 may be generated on the customer device 102 based on a seed 201, for example, a seed derived from a mnemonic code or sentence by Bitcoin Improvement Proposal 39 (BIP39) (available at https: / / github.com / bitcoin / bips / blob / master / bip-0039.mediawiki and incorporated herein by reference). Alternatively, the private account key 204 may be generated on the customer device 102 randomly, manually, or by other means.

[0040]

[0070] The private account key 204 may be used to derive the public account key 205; that is, the private account key 204 may determine the public account key 205. In the example, the customer device 102 may use a hash function to derive the public account key 205 from the private account key 204, for example, the SHA256 function. However, the public account key 205 does not typically (and preferably) determine the private account key 204; for example, the public account key 205 may not be used to generate the private account key 204.

[0041]

[0071] The private account key 204 and the public account key 205 can be “extended” keys, which means that a chaincode is appended to the key string. In the example, each of the private account key 204 and the public account key 205 may be 256 bits long with an additional 256 bits of chaincode, i.e., the extended private account key 204 and the extended public account key 205 may each be 512 bits long. Extended keys can be used to derive child keys, while non-extended (or “hardened”) keys cannot. Because these are extended keys, it may be desirable not to send the private account key 204 and the public account key 205 from the customer device 102 to the currency conversion system 104 or a trusted third party 106.

[0042]

[0072] The private account key 204 may have one or more optional child private transaction keys 206A-B at the second level (L2) of the node tree 200A. The private transaction key 206 can be derived from the private account key 204 using the child key derivation (CKD) function, for example, as described in BIP32. The private transaction key 206 may be an unenhanced (i.e., strengthened) key and cannot be used to derive further child keys.

[0043]

[0073] Each secret transaction key 206 is, for example, 0 to (2 32 It may have associated indexes in the range of -1). The indexes can be used to navigate the node tree 200A, that is, the indexes can uniquely identify the location of a particular secret transaction key 206. Thus, as an efficient method for identifying secret transaction keys 206, indexes can be sent between devices. In the example, a device receiving the indexes can generate the corresponding secret transaction key 206 from its own node tree.

[0044]

[0074] Similarly, the public account key 205 may have one or more optional public transaction keys 207A-B at the second level (L2) of the node tree 200A. Each public transaction key 207 can be derived from the public account key 205 or from an associated private transaction key 206 using a child key derivation (CKD) function (for example, as described in BIP32), i.e., public transaction key 207A may be derived from private transaction key 206A, and public transaction key 207B may be derived from private transaction key 206B. The public transaction keys 207 may be unextended (i.e., hardened) keys and cannot be used to derive further child keys. Thus, the private transaction key 206 and / or public transaction key 207 may be sent from the customer device 102 to the currency conversion system 104 and / or a trusted third party 106 for a multi-approval transaction requiring M keys out of N.

[0045]

[0075] Each public transaction key 207 is, for example, 0 to (2 32 It may have associated indexes in the range of -1). The indexes may be used to navigate the node tree 200A, that is, the indexes may uniquely identify the location of a particular public transaction key 207. Thus, the indexes may be transmitted between devices as an efficient method for identifying public transaction keys 207. In the example, a device receiving the indexes can generate the corresponding public transaction key 207 from its own node tree.

[0046]

[0076] In the example, node tree 200A may contain many (e.g., hundreds, thousands, millions, or billions) private transaction keys 206, for example, a new private transaction key 206 may be generated for every transaction in which cryptocurrency is received into a customer wallet, and / or for every transaction in which less cryptocurrency is transferred than the total amount of cryptocurrency in an existing transaction address. Furthermore, node tree 200A may contain many (e.g., hundreds, thousands, millions, or billions) public transaction keys 207, for example, corresponding to each private transaction key 206 in node tree 200A.

[0047]

[0077] Although shown with two hierarchical levels (L1-L2), node tree 200A can contain more hierarchical levels. In the example, the change key level (not shown) may be located between L1 and L2.

[0048]

[0078] Figure 2B is a block diagram showing another exemplary node tree 200B on the currency conversion system 104 for implementing customer wallets. In this example, node tree 200B can implement one or more HD wallets for one or more customers in accordance with part of BIP32 and / or part of BIP44.

[0049]

[0079] The node tree 200B may be stored in the currency conversion system 104 (for example, in the key repository 114) and may include hierarchical levels. However, unlike the node tree 200A of the customer device 102, the node tree 200B may include a master secret key 212 at the first level (L0). Specifically, the currency conversion system 104 may store a single master secret key 212 used to derive one or more secret account keys 214A~B. In other words, the master secret key 212 may be the parent secret key of all secret account keys 214 stored in the currency conversion system 104. Optionally, the master secret key 212 may be generated in the currency conversion system 104 based on a seed 211, for example, a seed derived from a mnemonic code or sentence according to BIP39. Alternatively, the master secret key 212 may be generated in the currency conversion system 104 randomly, manually, or by other means.

[0050]

[0080] The master private key 212 may be used to derive a master public key 213, which may be the parent public key for all public account keys 215A~B on the currency conversion system 104. The master private key 212 and master public key 213 may be extension keys. Therefore, it may be preferable to avoid transmitting the master private key 212 and master public key 213 from the currency conversion system 104.

[0051]

[0081] In the example, the first private account key 214A and the first public account key 215A may be maintained for a first customer, and the second private account key 214B and the second public account key 215B may be maintained for a second customer. Alternatively, the first private account key 214A and the first public account key 215A may be maintained for a first type of cryptocurrency held in the customer wallet, and the second private account key 214B and the second public account key 215B may be maintained for a second type of cryptocurrency held in the same customer wallet. The first and second types can be selected from Bitcoin, Ethereum, Litecoin, etc.

[0052]

[0082] In the example, node tree 200B may contain a private account key 214 and a public account key 215 for each customer for each cryptocurrency type. That is, if 10 customers each hold three different types of cryptocurrency in the currency conversion system 104, node tree 200B may contain 30 (i.e., 10 × 3) private account keys 214 and 30 public account keys 215. Since these are extended keys, it may be desirable not to send the private account keys 214 and public account keys 215 from the currency conversion system 104 to the customer device 102 or a trusted third party 106.

[0053]

[0083] The private account keys 214A-B and public account keys 215A-B at the second level (L1) of node tree 200B may correspond to (but are not identical to) private and public account keys stored on various customer devices 102 and trusted third parties 106.

[0054]

[0084] Similar to the node tree 200A of the customer device 102, the node tree 200B of the currency conversion system 104 may have one or more optional secret transaction keys 216A~D at, for example, the third level (L2) of node tree 200B. Each secret transaction key 216 may be derived from one of the secret account keys 214 using a child key derivation (CKD) function, for example, as described in BIP32.

[0055]

[0085] Node tree 200B may also have one or more optional public transaction keys 217A-D at the third level (L2). Each public transaction key 217 may be derived from one of the public account keys 215 using a child key derivation (CKD) function (as described, for example, in BIP32), or from an associated private transaction key 216. Alternatively, each public transaction key 217 may be derived directly from one of the private account keys 216 or one of the private account keys 214.

[0056]

[0086] The private transaction key 216 and the public transaction key 217 may be unextended (i.e., hardened) keys and cannot be used to derive further child keys. Therefore, the private transaction key 216 and / or the public transaction key 217 may be transmitted from the currency conversion system 104 to the customer device 102 and / or trusted third party 106 for multi-approval transactions requiring M out of N keys (e.g., 2 / 3).

[0057]

[0087] Each secret transaction key 216 is, for example, from 0 to (2 32 It may have associated indexes in the range of -1). The indexes can be used to navigate the node tree 200B, that is, the indexes can uniquely identify the location of a corresponding particular secret transaction key 216. Thus, as an efficient method for identifying secret transaction keys 216, indexes can be sent between devices. In the example, a device receiving the indexes can generate the corresponding secret transaction key 216 from its own node tree.

[0058]

[0088] Each public transaction key 217 is, for example, from 0 to (2 32It may have associated indexes in the range of -1). The indexes may be used to navigate the node tree 200B, that is, the indexes may uniquely identify the location of a particular public transaction key 217. Thus, the indexes may be transmitted between devices as an efficient method for identifying public transaction keys 217. In the example, a device receiving the indexes can generate the corresponding public transaction key 217 from its own node tree.

[0059]

[0089] In the example, node tree 200B may contain many (e.g., hundreds, thousands, millions, or billions) private transaction keys 216, for example, a new private transaction key 216 may be generated for every transaction in which cryptocurrency is received into a customer wallet, and / or for every transaction in which less cryptocurrency is transferred than the total amount of cryptocurrency in an existing transaction address. Furthermore, node tree 200B may contain many (e.g., hundreds, thousands, millions, or billions) public transaction keys 217, for example, corresponding to each private transaction key 216 in node tree 200B.

[0060]

[0090] Although shown with three hierarchical levels (L0-L2), node tree 200B can contain more hierarchical levels. In the example, the change key level (not shown) may be located between L1 and L2.

[0061]

[0091] Figure 2C is a block diagram showing another exemplary node tree 200C on a trusted third party 106 for implementing customer wallets. In this example, node tree 200C can implement one or more HD wallets for one or more customers in accordance with parts of BIP32 and / or parts of BIP44.

[0062]

[0092] The node tree 200C may be stored in a trusted third party 106 (for example, within the key repository 116) and may include hierarchical levels. The node tree 200C is a single master secret associated with the first level (L0) currency conversion system 104. Key 222 may contain a key that can be used to derive one or more secret account keys 224A-B of accounts associated with the currency conversion system 104. In other words, the master secret key 222 can be the parent secret key of all secret account keys 224 on the trusted third party 106 associated with the currency conversion system 104, even if the trusted third party 106 contains other master secret keys (not shown) not associated with the currency conversion system 104. The master secret key 222 may have a different value from the master secret key 212 of the node tree 200B of the currency conversion system 104. Optionally, the master secret key 222 may be generated by the trusted third party 106 based on a seed 221, for example, a seed derived from a mnemonic code or sentence by BIP39. Alternatively, the master secret key 222 may be generated randomly or by other means by the trusted third party 106.

[0063]

[0093] The master private key 222 may be used to derive a master public key 223, which may be the parent public key for all public account keys 225A-B on a trusted third party 106. The master private key 222 and master public key 223 may be extended keys. Even if the master public key 223 is an extended key, it may be transmitted from the trusted third party 106 to the currency conversion system 104. The master public key 223 may be shared with the currency conversion system 104 by secure and / or non-electronic means without transmitting the master public key 223 over a network such as the Internet. In the example, the master public key 223 may be copied to secure portable memory (e.g., a portable hard drive) which is physically moved to and downloaded to the currency conversion system 104. Alternatively, the master public key 223 may be manually handwritten (or otherwise printed) on a hard copy and transferred to the currency conversion system 104, where it may be manually entered. Alternatively, the master public key 223 may be encrypted and transmitted to the currency conversion system 104 over a network (e.g., the Internet).

[0064]

[0094] In this example, the first private account key 224A and the first public account key 225A may be maintained for a first customer, and the second private account key 224B and the second public account key 225B may be maintained for a second customer. Alternatively, the first private account key 224A and the first public account key 225A may be maintained for a first type of cryptocurrency held in a customer wallet, and the second private account key 224B and the second public account key 225B may be maintained for a second type of cryptocurrency held in a customer wallet, etc. For example, the first and second types can be selected from Bitcoin, Ethereum, Litecoin, etc. In the example, node tree 200C may contain a private account key 224 and a public account key 225 for each customer for each cryptocurrency type. That is, if 10 customers each hold three different types of cryptocurrency with a trusted third party 106, node tree 200C may contain 30 (i.e., 10 × 3) private account keys 224 and 30 public account keys 225. Since these are extended keys, it may be desirable to avoid sending the private account keys 224 and public account keys 225 from the trusted third party 106 to the customer device 102 or the currency conversion system 104.

[0065]

[0095] The secret account keys 224A-B and public account keys 225A-B at the second level (L1) of node tree 200C may correspond to (but are not identical to) the secret account keys 204 and public account keys 205 in node tree 200A on customer device 102, and to (but are not identical to) the secret account keys 214A-B and public account keys 215A-B in node tree 200B of currency conversion system 104. The public account key 205 of customer device 102, the first public account key 215A of currency conversion system 104, and the first public account key 225A of trusted third party 106 may correspond to (but are not identical to) each other. In the example, to create a multi-approval transaction address Therefore, all three public account keys 205, 215A, and 225A may be required. Similarly, the private account key 204 of customer device 102, the first private account key 214A of currency conversion system 104, and the first private account key 224A of trusted third party 106 may correspond to each other (but not identical). In the example, at least two of the private account keys 204, 214A, and 224A may be required to conduct a transaction from a multi-approval transaction address.

[0066]

[0096] Similar to the node tree 200A of the customer device 102 and the node tree 200B of the currency conversion system 104, the node tree 200C of a trusted third party 106 may have one or more optional private transaction keys 226A-D at, for example, the third level (L2) of node tree 200C. Each private transaction key 226 may be derived from one of the private account keys 224 using a child key derivation (CKD) function, for example, as described in BIP32.

[0067]

[0097] The node tree 200C may have one or more optional public transaction keys 227A-D at the third level (L2). Each public transaction key 227 may be derived from one of the public account keys 225 using a child key derivation (CKD) function or an associated private transaction key 226 (as described, for example, in BIP32). Alternatively, each public transaction key 227 may be derived directly from one of the private transaction keys 226 or from one of the private account keys 224.

[0068]

[0098] The private transaction key 226 and the public transaction key 227 may be unextended (i.e., hardened) keys and cannot be used to derive further child keys. Therefore, the private transaction key 226 and / or the public transaction key 227 may be transmitted from a trusted third party 106 to the customer device 102 and / or the currency conversion system 104 for multi-approval transactions requiring M out of N keys.

[0069]

[0099] Each secret transaction key 226 is, for example, 0 to (2 32 A range of associated indexes can be found in the node tree 200C. The index can be used to navigate the node tree 200C, that is, the index can uniquely identify the location of a corresponding specific secret transaction key 226. Thus, as an efficient method for identifying secret transaction keys 226, indexes can be transmitted between devices. In the example, a device receiving the index can generate the corresponding secret transaction key 226 from its own node tree. Furthermore, a specific secret transaction key 226 in node tree 200C may correspond to a specific secret transaction key 206 in node tree 200A on customer device 102, and a specific secret transaction key 226 in node tree 200B on currency conversion system 104 (and may have the same index as them). For example, secret transaction keys 206A, 216A, and 226A may correspond to each other and have the same index.

[0070]

[0100] Each public transaction key 227 is, for example, 0 to (2 32-1) may have associated indexes within a range. The indexes may be used to navigate the node tree 200C, that is, the indexes may uniquely identify the location of a corresponding particular public transaction key 227. Thus, the indexes may be transmitted between devices as an efficient method for identifying public transaction keys 227. In the example, a device receiving the indexes can generate the corresponding public transaction key 227 from its own node tree. Furthermore, a specific public transaction key in the node tree 200C may be generated. Transaction keys 227 can correspond to (and have the same index as) a specific public transaction key 207 in node tree 200A on customer device 102 and a specific public transaction key 227 in node tree 200B on currency conversion system 104. For example, public transaction keys 207A, 217A, and 227A can correspond to each other and have the same index.

[0071]

[0101] In the example, node tree 200C may contain many (e.g., hundreds, thousands, millions, or billions) private transaction keys 226, for example, a new private transaction key 226 is generated for every transaction in which cryptocurrency is received into a customer wallet and / or for every transaction in which less cryptocurrency is transferred than the total amount of cryptocurrency in an existing transaction address. Furthermore, node tree 200B may contain many (e.g., hundreds, thousands, millions, or billions) public transaction keys 227, for example, corresponding to each private transaction key 226 in node tree 200B.

[0072]

[0102] Although shown with three hierarchical levels (L0-L2), node tree 200C can contain more hierarchical levels. In the example, the change key level (not shown) may be located between L1 and L2.

[0073]

[0103] Figure 3 is a flowchart illustrating an exemplary method 300 for onboarding a customer in a multi-signature system. Method 300 can be performed by a customer device 102, a currency conversion system 104, a trusted third party 106, and an identity service provider 110 within the system 100 shown in Figure 1.

[0074]

[0104] The customer may optionally download the application to their customer device 102 (for example, from an app store) and create (or modify) a customer wallet 302. Alternatively, the application may be previously downloaded and installed on the customer device 102 during manufacturing. The application may be created by a currency conversion system 104, for example, a money services business (MSB). The application may interface with the customer and communicate with the currency conversion system 104 (for example, using a user interface). Creating (or modifying) a customer wallet may include generating a first (or subsequent) private account key 204 on the customer device 102, either randomly or manually, based on a seed 201. Alternatively, creating a customer wallet may include the customer entering an existing private account key 204 into the application; for example, the customer may manually transcribe or copy an existing private account key 204 and paste it into the application.

[0075]

[0105] Customers can also enter identity data and payment data into the application.304 Identity data may include the customer's name, date of birth, driver's license number and expiration date, address, phone number, email address, social security number, image of the customer's government-issued photo ID, a photo of the customer holding the government-issued photo ID, employment information, and / or income. Identity data may also include biometric data such as fingerprint data (e.g., a scan of the customer's fingerprints), retinal scan data (e.g., an image of the customer's retina), facial recognition data (e.g., an image of the customer's face), and / or voice data (e.g., a recording of the customer's voice). Instead of raw biometric data (e.g., images and / or recordings), the application may only transmit processed data derived from raw biometric data, such as image features, voice features, etc.

[0076]

[0106] Payment data may include bank account information, credit card information, contactless payment data (e.g., username and password for Apple Pay® or Android Pay®), existing cryptocurrency wallet keys, and / or other payment processing information (e.g., name and password for PayPal® or WhatsApp®). The customer device 102 may transmit the customer-associated identity data and payment data to the currency conversion system 104 306, for example, using a secure transfer protocol.

[0077]

[0107] The currency conversion system 104 may transmit identity data to the identity service provider 110 308. The identity service provider 110 may use the transmitted customer identity data to perform anti-money laundering (AML) procedures and / or customer verification (KYC) procedures 310. AML may attempt to verify that the customer is not laundering money, that is, that the customer is not taking steps to conceal sources of funds received from illegal or unethical activities. KYC may verify that the customer is who they claim to be and that they are not on any law enforcement watchlists. KYC may also assess creditworthiness (for example, in a soft credit check), analyze the customer's transactional behavior, and monitor the customer's account for any fraudulent activity based on the customer's transactional behavior. Once the AML and / or KYC procedures are complete, the identity service provider 110 may send a notification 312 to the currency conversion system 104 and a trusted third party 106. The notification may indicate the success or failure of the customer's AML and / or KYC procedures. For example, the identity service provider 110 may send a report showing all the AML and KYC checks it performed.

[0078]

[0108] If the notification indicates that all (or all required) AML and KYC checks have been passed, the currency conversion system 104 may create a customer account 314 based on the notification. Creating an account may include generating a private account key 214 in the currency conversion system 104 for the customer. The currency conversion system 104 may derive the customer's private account key 214 from the master private key 212 with a new index, for example, using the Child Key Derivation (CKD) function by BIP 32.

[0079]

[0109] If a notification from the identity service provider 110 indicates that all (or all required) AML and KYC checks have been passed, the trusted third party 106 may also create an account for the customer based on the notification. Creating an account may involve the trusted third party 106 generating a private account key 224 for the customer. The trusted third party 106 may, for example, use the Child Key Derivation (CKD) function by BIP32 to derive the customer's private account key 224 from the master private key 222 with a new index.

[0080]

[0110] If the notification indicates that not all (or all required) AML and KYC checks have been passed, the currency conversion system 104 may notify the customer (via the application) that the AML and / or KYC checks have failed. Alternatively, if the notification indicates that the AML and / or KYC checks could not be completed with the identity data, the currency conversion system 104 may request further information from the customer.

[0081]

[0111] Figure 4 is a flowchart illustrating an exemplary method 400 for purchasing cryptocurrency in a multi-signature system. Method 400 can be performed by a customer device 102, a currency conversion system 104, a trusted third party 106, and an asset exchange 108 within the system 100 shown in Figure 1.

[0082]

[0112] Customers can create cryptocurrency buy orders 402 on an application on their customer device 102. A cryptocurrency buy order may specify the type of cryptocurrency (e.g., Bitcoin, Ethereum, etc.) and the desired quantity (in terms of cryptocurrency or fiat currency such as US dollars). A cryptocurrency buy order may also specify optional attributes such as limit price, stop price, conditional trigger requirements, order duration, and whether the order is partially executed. While creating a cryptocurrency buy order, customers may be required to provide biometric input and / or a password to their customer device 102.

[0083]

[0113] Optionally, customer device 102 can sign cryptocurrency purchase orders using a private key stored in customer device 102, and for example, cryptocurrency purchase orders can optionally be encrypted using a private key (or a public key derived from a private key) stored in customer device 102. Cryptocurrency purchase orders may also include a public address (of the customer wallet) derived from a public or private key stored in customer device 102.

[0084]

[0114] The customer device 102 can transmit cryptocurrency purchase orders and customer payment data to the currency conversion system 104. The customer payment data may include instructions to use payment data that has not been previously stored in the currency conversion system 104, or payment data that has been previously stored in the currency conversion system 104. Optionally, the customer device 102 can transmit customer identity data, such as biometric data.

[0085]

[0115] In response to a cryptocurrency purchase order, the currency conversion system 104 processes customer payment data 406, optionally verifies identity data, and sends a custody order 408 to the asset exchange 108 for the purchase of cryptocurrency into the custody wallet. The currency conversion system 104 may also send custody payment data along with the custody order. The custody payment data may indicate that the asset exchange 108 needs to withdraw funds from the custody account. Optionally, the currency conversion system 104 may sign the custody order using a private key stored in the currency conversion system 104, for example, the custody order may optionally be encrypted using a private key (or a public key derived from a private key) stored in the currency conversion system 104. The custody order may also include a public address (of the custody wallet) derived from a public or private key stored in the currency conversion system 104. The custody wallet may be named to the currency service system 104, for example, a money service business (MSB). Upon receipt, the asset exchange 108 may execute the custody order and place the cryptocurrency into the custody wallet 410.

[0086]

[0116] Simultaneously or nearly simultaneously with the submission of the custody order, the currency conversion system 104 may also notify a trusted third party 106 412 of the cryptocurrency purchase order, custody order, and / or the new transaction address in the customer wallet. The currency conversion system 104 may generate a new transaction address for the customer wallet. This may involve generating the transaction address for the customer wallet by using N public transaction keys (e.g., 207A, 217A, 227A) as inputs to a multi-affirmation hash function (along with multi-affirmation condition inputs).

[0087]

[0117] A trusted third party 106 can act as a trusted party that authorizes certain types of transactions in the asset exchange 108. This decentralizes the keys for approving transactions, which could make system 100 vulnerable to malicious attacks. Furthermore, the trusted third party 106 can send A gold license may be owned, but a currency conversion system 104 may not. A trusted third party 106 can instruct the asset exchange 108 to transfer the cryptocurrency associated with a custody order from the custody wallet to a new transaction address in the customer wallet 416. Upon receiving instructions from the trusted third party 106, the asset exchange can record the change of ownership of the cryptocurrency from the custody wallet to the new transaction address in the customer wallet 416 in the distributed ledger 118 (e.g., the blockchain).

[0088]

[0118] The currency conversion system 104 can send the new transaction address and / or the private key associated with the new transaction address in the customer wallet to the customer device 102. The customer device 102 can then make a transaction from the new transaction address only if it possesses M (for example, 2 / 3 based on multi-approval condition input) of the N private transaction keys associated with the N public transaction keys, such as 206A, 216A, 226A. In this example, the currency conversion system 104 may wait until the customer's payment is completed, for example, 1-2 days for credit card payments or 3-5 days for electronic transfers, before sending the new transaction address and / or the private key associated with the new transaction address to the customer device 102.

[0089]

[0119] Figure 5 is a block diagram illustrating an exemplary currency conversion system 104 for generating a multi-approval transaction address 530. To generate the multi-approval transaction address 530, the currency conversion system 104 may require N (for example, 3) public transaction keys 207A, 217A, and 227A.

[0090]

[0120] The currency conversion system 104 can receive the public transaction key 207A from the customer device 102. The public transaction key 207A can be used to derive transaction addresses, monitor transactions at transaction addresses, and / or display account balances (e.g., on the blockchain), but the public transaction key 207A may not be used to conduct transactions from the account. Furthermore, since the public transaction key 207A is hardened (i.e., not extended), it may not be used to derive child keys. Therefore, the risk of the customer device 102 sharing the public transaction key 207A with the currency conversion system 104 is relatively low.

[0091]

[0121] The currency conversion system 104 can also derive the public transaction key 217 from the node tree 200B stored in the currency conversion system 104. In the example, the currency conversion system 104 can derive the public transaction key 217 from the public account key 215, which is derived from the master public key 213, which is optionally derived from the master private key 212. Alternatively, the currency conversion system 104 can derive the public transaction key 217 from the private account key 214, which is derived from the master private key 212. Alternatively, the currency conversion system 104 can derive the public transaction key 217 from the public account key 215, which is derived from the private account key 214, which is derived from the master private key 212. In any case, the public transaction key 217 can be derived from the node tree 200B stored in the currency conversion system 104.

[0092]

[0122] The currency conversion system 104 can also derive a public transaction key 227 from a master public key 223 received from a trusted third party 106. In this case as well, since the master public key 223 is "public", it cannot be used in a transaction or used to derive a private key that can be used in a transaction. However, the master The public key 223 can be used to derive public account keys 225 for many different customers and can therefore be securely transferred from a trusted third party 106 to the currency conversion system. Specifically, the master public key 223 from the trusted third party 106 can be shared with the currency conversion system 104 by secure and / or non-electronic means without transmitting the master public key 223 over a network such as the internet. In the example, the master public key 223 may be copied to secure portable memory (e.g., a portable hard drive) which is physically moved to and downloaded to the currency conversion system 104. Alternatively, the master public key 223 may be manually handwritten (or otherwise printed) on a hard copy and transferred to the currency conversion system 104, where it is manually entered. Alternatively, the master public key 223 may be encrypted and transmitted to the currency conversion system 104 over a network (e.g., the internet).

[0093]

[0123] Once the public account key 225 is stored in the currency conversion system 104, it can be derived from the master public key 223. The currency conversion system 104 can then derive the public transaction key 227A from the public account key 225.

[0094]

[0124] Next, the currency conversion system 104 can input the three public transaction keys 207A, 217A, and 227A into the multi-approval hash module 528 and generate a multi-approval transaction address 530 along with the multi-approval conditions 529. The multi-approval hash module 528 can use a hash algorithm to generate the multi-approval transaction address 530, such as a pay-to-script hash (P2SH), as defined in BIP16 or other public key scripts. It should be noted that the resulting multi-approval transaction address 530 is different from a normal transaction address, since M private keys (specified in the multi-approval conditions 529) associated with the N input public keys are required to transaction from the multi-approval transaction address 530. In the example, the multi-approval conditions 529 specify that two private keys (for example, two of the private transaction keys 206A, 216A, and 226A) associated with the three public transaction keys 207A, 217A, and 227A are required to transaction from the multi-approval transaction address 530.

[0095]

[0125] The currency conversion system 104 can send a multi-confirmation transaction address 530 to the customer device 102. The customer device 102 can then make transactions from the multi-confirmation transaction address 530 using an appropriate number of secret transaction keys. In the example, the secret transaction key 206A stored in the customer device 102 and the secret transaction key 216A stored in the currency conversion system 104 (and transferred to the customer device 102) can preferably be used to make transactions from the multi-confirmation transaction address 530. The secret transaction key 226A in a trusted third party 106 (along with the secret transaction key 216A in the currency conversion system 104) can be used to restore the customer wallet if the customer device 102 is lost, damaged, upgraded, or hard reset / reformatted.

[0096]

[0126] Figure 6 is a flowchart illustrating method 600 for generating a multi-confirmation transaction address 530. Method 600 can be performed by the currency conversion system 104. Method 600 can be performed whenever a new transaction address is needed in the customer wallet. In the example, method 600 is used to generate a multi-confirmation transaction address 530, to create a multi-confirmation transaction address 530 to store newly purchased cryptocurrency, or during a cryptocurrency transaction. For example, a new multi-confirmation transaction address 530 could be created in response to a customer request to store the remaining cryptocurrency after the transaction.

[0097]

[0127] Optionally, the currency conversion system 104 can verify identity data 602 from the customer device 102. In an example, the identity data may include the customer's name, date of birth, driver's license number and expiration date, address, telephone number, email address, social security number, image of the customer's government-issued photo ID, photograph of the customer holding the government-issued photo ID, employment information, and / or income. The identity data may also include biometric data such as fingerprint data (e.g., a scan of the customer's fingerprints), retinal scan data (e.g., an image of the customer's retina), facial recognition data (e.g., an image of the customer's face), and / or voice data (e.g., a recording of the customer's voice). Instead of raw biometric data (e.g., images and / or recordings), the identity data may include processed data derived from raw biometric data, such as image features, voice features, etc.

[0098]

[0128] The currency conversion system 104 can verify the customer's identity data received from the customer device 102 by comparing the received biometric data with previously stored biometric data, for example, biometric data stored when the customer first created their account with the currency conversion system 104.

[0099]

[0129] Optionally, the currency conversion system 104 can determine a first public key derived from a first parent public key. In the example, the currency conversion system 104 can receive a public transaction key 207A from a customer device 102 that has already derived the public transaction key 207A from the public account key 205 and / or the private account key 204. In other words, the first public key could be the public transaction key 207A from the node tree 200A stored in the customer device 102, and the first parent public key could be the public account key 205 or the private account key 204.

[0100]

[0130] Optionally, the currency conversion system 104 may also determine a second public key derived from a second parent public key (for example, a public transaction key 217 in the node tree 200B stored in the currency conversion system 104). In the example, the currency conversion system 104 can derive the public transaction key 217 from the node tree 200B stored in the currency conversion system 104. In the example, the public transaction key 217 is optionally derived from a public account key 215, which is derived from a master public key 213, which is derived from a master private key 212. Alternatively, the public transaction key 217 may be derived from a private account key 214, which is derived from a master private key 212. Alternatively, the public transaction key 217 may be derived from a public account key 215, which is derived from a private account key 214, which is derived from a master private key 212. Therefore, the second parent public key could be the public account key 215, master public key 213, master private key 212, or private account key 214 in the node tree 200B stored in the currency conversion system 104.

[0101]

[0131] Optionally, the currency conversion system 104 may also determine a third public key derived from a third parent public key 608. In the example, the currency conversion system 104 may derive a public transaction key 227 from a public account key 225 optionally derived from a master public key 223 previously received from a trusted third party 106. Alternatively, the currency conversion system 104 may derive a public transaction key 227 from a master public key 223 previously received from a trusted third party 106. In other words, the third public key could be the public transaction key 227, and the third master key could be the master public key 223 or the public account key 225, respectively.

[0102]

[0132] The currency conversion system 104 can also derive a multi-approval transaction address 530 from a first public key derived from a first parent public key, a second public key derived from a second parent public key, and a third public key derived from a third parent public key using a hash function (for example, a pay-to-script hash (P2SH) as defined in BIP16 or other public key scripts). The multi-approval transaction address 530 may require private keys associated with at least M (e.g., 2) of the first public key, the second public key, and the third public key in order to conduct transactions from the multi-approval transaction address 530.

[0103]

[0133] The currency conversion system 104 can send the multi-approval transaction address 530 and / or the private transaction key 226 associated with the second public key 227 to the customer device 102. The customer device 102 can then perform transactions from the multi-approval transaction address 530 using the private transaction keys associated with at least two of the public transaction keys 207A, 217A, and 227A. For example, the private transaction key 206A stored in the customer device 102 and the private transaction key 216A stored in the currency conversion system 104 can typically be used to perform transactions from the multi-approval transaction address 530. Alternatively, during customer wallet restoration, transactions can be performed from the multi-approval transaction address 530 using the private transaction key 216A stored in the currency conversion system 104 and the private transaction key 226A stored in the trusted third party 106.

[0104]

[0134] Figure 7A is a flowchart illustrating an exemplary method 700A for cryptocurrency transactions in a multi-recognition system, such as using cryptocurrency for goods or services. Method 700A can be performed by a customer device 102, a currency conversion system 104, and optionally, a trusted third party 106 within the system 100 shown in Figure 1.

[0105]

[0135] System 100 can optionally distribute one or more first secret transaction keys 206 to the customer device 102, one or more second secret transaction keys 216 to the currency conversion system 104, and one or more third secret transaction keys 226 to a trusted third party 106. In this example, the secret transaction keys 206, 216, and 226 may be derived from the secret account keys 204, 214, and 216 of the customer device 102, the currency conversion device 104, and the trusted third party 106, respectively.

[0106]

[0136] To initiate a cryptocurrency transaction, a customer can open an application on their device 102 using authentication data 704. In this example, the authentication data may include biometric data, such as the customer placing a finger on a fingerprint reader, pointing a camera at their face, pointing a camera at their eyes, or speaking into a microphone. In this example, the application may only open (or grant certain access) if the biometric data matches biometric data uploaded during onboarding. Alternatively, the authentication data may be a password, or a combination of biometric data and a password. Once the user has access to the application, the customer can make a transaction request in the application 706.

[0107]

[0137] A transaction request can specify the type and amount of cryptocurrency to be transferred, for example, 0.15 Bitcoin. A transaction request can also be conditionally triggered. The transaction request may also include optional attributes such as the duration of the transaction request. The transaction request may also include the transaction address of the destination wallet to which the cryptocurrency will be transferred.

[0108]

[0138] The transaction request may be signed 708 based on a first secret transaction key 206 and a second secret transaction key 216. Specifically, an application on the customer device 102 can identify a multi-confirmation transaction address 530 with sufficient cryptocurrency to satisfy the transaction request. If a single multi-confirmation transaction address 530 cannot be identified with sufficient cryptocurrency, the application can identify multiple multi-confirmation transaction addresses 530 with sufficient cumulative cryptocurrency to satisfy the transaction request. The application then inputs the first secret transaction key 206 and the second secret transaction key 216 of each identified multi-confirmation transaction address 530 into a redemption script (for example, a redemption script following BIP16) to transaction from each multi-confirmation transaction address 530.

[0109]

[0139] Once a transaction request is signed, the transaction can be sent to an asset exchange 108 for recording on a distributed ledger 118, such as a blockchain.

[0110]

[0140] Figure 7B is a flowchart illustrating an exemplary method 700B for cryptocurrency transactions in a key-splitting system, such as using cryptocurrency for goods or services. Method 700B can be performed by a customer device 102, a currency conversion system 104, and optionally, a trusted third party 106 within the system 100 shown in Figure 1.

[0111]

[0141] System 100 can optionally distribute a first private key component to the customer device 102, a second private key component to the currency conversion system 104, and a third private key component to a trusted third party 106. In the example, the private key components may be generated from the private transaction key 206 on the customer device, for example, using polynomial interpolation or Shamir secret sharing. In the example, an M / N (e.g., 2 / 3) key component may be required to reconstruct the private transaction key 206 used to sign cryptocurrency transactions from a specific transaction address. In the example, the third private key component is used only in emergencies, for example, if the customer device 102 containing the first private key component is lost, damaged, upgraded, or hard reset / reformatted.

[0112]

[0142] To initiate a cryptocurrency transaction, a customer can open an application on their device 102 using authentication data 714. In this example, the authentication data may include biometric data, such as the customer placing a finger on a fingerprint reader, pointing a camera at their face, pointing a camera at their eyes, or speaking into a microphone. In this example, the application can only be opened if the biometric data matches the biometric data uploaded during onboarding. Alternatively, the authentication data may be a password, or a combination of biometric data and a password. Once the user has access to the application, the customer can make a transaction request in the application 716.

[0113]

[0143] A transaction request may specify the type and amount of cryptocurrency to be transferred, for example, 0.15 Bitcoin. A transaction request may also include optional attributes such as conditional trigger requirements and the duration of the transaction request. A transaction request may also include the public address of the destination wallet to which the cryptocurrency will be transferred.

[0114]

[0144] A transaction request can be signed 718 based on a first private key component and a second private key component. In a key splitting configuration, a transaction request can be signed 718 by reconstructing a private transaction key 206 using two or more key components, and then signing the transaction request using the reconstructed private transaction key 206, for example, as shown in Figure 8E.

[0115]

[0145] Once a transaction request is signed, the transaction may be sent to an asset exchange 108 for recording on a distributed ledger 118, such as a blockchain.

[0116]

[0146] Figures 8A to 8E show five different options for signing a transaction request. Specifically, Figures 8A to 8D show different implementations of element 708 in Figure 7A, and Figure 8E shows an implementation of element 718 in Figure 7B.

[0117]

[0147] Figure 8A is a flowchart illustrating a first exemplary method 800A for signing a transaction request using multisig. Method 800A may be performed by a customer device 102 requesting a transaction with cryptocurrency. The customer device 102 may identify one or more multi-confirmation transaction addresses 530 with sufficient cryptocurrency to satisfy the transaction request. In other words, the customer device 102 may find one or more previously generated multi-confirmation transaction addresses 530 of the correct type and that cumulatively hold at least a sufficient amount of cryptocurrency to satisfy the customer's desired transaction, such as 0.15 Bitcoin. One or more multi-confirmation transaction addresses 530 may be created during the purchase of cryptocurrency, during a previous cryptocurrency transaction to store the remaining cryptocurrency, and / or at the customer's request.

[0118]

[0148] The customer device 102 can also identify one or more first secret transaction keys 206 associated with one or more multi-authorization transaction addresses 530. The first secret transaction keys 206 may be stored in the node tree 200A on the customer device 102. The first secret transaction keys 206 may be hardened (i.e., unextended) keys.

[0119]

[0149] The customer device 102 can also identify one or more second secret transaction keys 216 associated with one or more multi-confirmation transaction addresses 530. The second secret transaction keys 216 may initially be stored in the node tree 200B on the currency conversion system 104 and then sent to the customer device 102. In the example, the second secret transaction keys 216 may be sent to the customer device 102 when one or more multi-confirmation transaction addresses 530 are created during a previous cryptocurrency transaction to store funds provided and / or remaining cryptocurrency, for example, during the purchase of cryptocurrency. The second secret transaction keys 216 may be hardened (i.e., unextended) keys.

[0120]

[0150] The customer device 102 may sign a transaction request 807 using one or more first secret transaction keys 206 and one or more second secret transaction keys 216. The signing may include, for example, verifying that the first and second secret transaction keys 216 corresponding to each source multi-approved transaction address 530 have been entered, and then generating the signed transaction using a redemption script (for example, in accordance with BIP 16).

[0121]

[0151] Optionally, the customer device can send a request to the currency conversion system 104 809 to create a new multi-confirmation transaction address 530 to hold the remaining funds after the transaction. For example, if the transaction request was to transfer 0.15 Bitcoin from a multi-confirmation transaction address 530 that holds 0.5 Bitcoin, the remaining 0.35 Bitcoin could be transferred to a new multi-confirmation transaction address 530 created by the currency conversion system 104.

[0122]

[0152] To create a new multi-approval transaction address 530, the currency conversion system 104 can use the three public transaction keys 207, 217, and 227 from the customer device 102, the currency conversion system 104, and a trusted third party 106, respectively, as illustrated in Figures 5 and 6.

[0123]

[0153] Figures 8B to 8D assume that a first secret transaction key 206A, a second secret transaction key 216A, and optionally a third secret transaction key 226A have been previously distributed to the customer device 102, the currency conversion system 104, and a trusted third party 106, respectively.

[0124]

[0154] Figure 8B is a flowchart illustrating a second exemplary method 800B for signing a transaction request using multisig. In method 800B, the customer device 102 can send biometric data and a request for a second secret transaction key 216A to the currency conversion system 104 802. This may include sending an index of the secret account key 214A stored in the node tree 200B on the currency conversion device 104. The currency conversion system 104 can receive the request, verify that the biometric data matches the customer's stored biometric data, and verify that AML has been previously performed on the customer 804.

[0125]

[0155] The currency conversion system 104 may transfer the second secret transaction key 216A, for example, the second secret transaction key 216A identified using the index and secret account key 214A from the customer device 102, to the customer device 102 806. The customer device 102 may then sign the transaction request 808 using the first secret transaction key 206A (stored in the customer device 102) and the second secret transaction key 216A (received from the currency conversion system 104). The signing may include, for example, verifying that the first secret transaction key 206A and the second secret transaction key 216A corresponding to the multi-approval transaction address 530 have been entered, and then generating the signed transaction using a redemption script (for example, according to BIP 16).

[0126]

[0156] Optionally, the customer device 102 may delete the second secret transaction key 216A (received from the currency conversion system 104) immediately after adding the second signature to the transaction request.

[0127]

[0157] Figure 8C is a flowchart showing a third exemplary method 800C for signing a transaction request using multisig. In method 800C, customer device 102 can sign the transaction request 812 using a first secret transaction key 206A stored in customer device 102. Customer device 102 can send the partially signed transaction request 814 to currency conversion system 104. Currency conversion system 104 can sign the transaction request 816 using a second secret transaction key 216A stored in currency conversion system 104. Currency conversion system 104 sends the fully signed transaction request to customer device 10 2 can send 818.

[0128]

[0158] Figure 8D is a flowchart illustrating a fourth exemplary method 800D for signing a transaction request using multisig. In method 800D, customer device 102 can send an unsigned transaction request to currency conversion system 104 822. Currency conversion system 104 can sign the transaction request 824 using a second secret transaction key 216A stored in currency conversion system 104. At this point, the transaction request can only be partially signed because a transaction may require signing using two out of three secret transaction keys (for example, two out of secret transaction keys 206A, 216A, and 226A). Therefore, currency conversion system 104 can send the partially signed transaction request back to customer device 102 826. Customer device 102 can sign the transaction request 828 using a first secret transaction key 206A stored in customer device 102.

[0129]

[0159] Figure 8E is a flowchart illustrating method 800E for signing a transaction request using key partitioning. Figure 8E assumes that a private transaction key has been pre-partitioned into a set of at least two (or three) key components, for example, using polynomial interpolation or Shamir secret sharing. Figure 8E also assumes that the first private key component, the second private key component, and optionally the third private key component have been pre-distributed by the customer device 102, the currency conversion system 104, and the trusted third party 106, respectively.

[0130]

[0160] In method 800E, the customer device 102 may send biometric data and a request for a second private key component to the currency conversion system 104 832. The currency conversion system 104 may receive this request, verify that the biometric data matches the customer's stored biometric data, and verify that AML has been previously performed on the customer 834. The currency conversion system 104 may also transfer the second private key component to the customer device 102 836. The customer device 102 may reconstruct the private key using the first private key component (stored in the customer device 102) and the second private key component (received from the currency conversion system 104) 838. The customer device 102 may sign the transaction request using the reconstructed private transaction key 840. Optionally, the customer device 102 may delete the second private key component (received from the currency conversion system 104) and / or the reconstructed private key immediately after adding the signature to the transaction request 842.

[0131]

[0161] Figure 9A is a flowchart illustrating an exemplary method 900A for recovering a customer wallet after the loss of a customer's key using multisignature. Method 900A may be performed by the currency conversion system 104 shown in Figure 1. Method 900A may be performed in response to a customer losing or destroying a device (e.g., a mobile device) that stores the keys to their customer wallet. Method 900A may also be performed when a customer purchases a new mobile device (i.e., upgrades) or when a customer hard resets / reformats their mobile device.

[0132]

[0162] The currency conversion system 104 can receive customer identity data and a request to restore the customer wallet from the customer device 102 901. In an example, the identity data may include the customer's name, date of birth, driver's license number and expiration date, address, telephone number, email address, social security number, image of the customer's government-issued photo ID, photograph of the customer holding the government-issued photo ID, employment information, and / or income. The identity data may also include fingerprint data (for example, the customer's fingerprints) This may also include biometric data such as a facial scan, retinal scan data (e.g., an image of the customer's retina), facial recognition data (e.g., an image of the customer's face), and / or voice data (e.g., a recording of the customer's voice). Instead of raw biometric data (e.g., images and / or recordings), identity data may include processed data derived from raw biometric data, such as image features, voice features, etc.

[0133]

[0163] The currency conversion system 104 can verify the customer's identity data received from the customer device 102 903. In this example, verification may include comparing the received biometric data with previously stored biometric data, for example, biometric data stored when the customer first created an account with the currency conversion system 104.

[0134]

[0164] Once the identity data received from the customer device is verified (i.e., the received biometric data matches previously stored biometric data), the currency conversion system 104 can communicate 905 a request to the key repository of a trusted third party 106 for a first key associated with the customer wallet. In this example, the first key may be a secret transaction key 226 stored in the trusted third party 106.

[0135]

[0165] The currency conversion system 104 may also receive a first key associated with the customer wallet from a key repository for a trusted third party 106 907. The currency conversion system 104 may also use the first key associated with the customer wallet and a second key associated with the customer wallet to restore the customer wallet 909. In this example, the second key may be a secret transaction key 226 stored in the currency conversion system 104.

[0136]

[0166] Optionally, the currency conversion system 104 may also change its internal settings 911 to indicate that transaction requests from the customer's old customer device 102 should no longer be signed or executed.

[0137]

[0167] Figure 9B is a flowchart illustrating another exemplary method 900B for recovering a customer wallet after the loss of a customer's key using multisignature. Method 900B may be performed by the currency conversion system 104 shown in Figure 1. Method 900B may be performed in response to a customer losing or destroying a device (e.g., a mobile device) that stores the keys to their customer wallet. Method 900B may also be performed when a customer purchases a new mobile device (i.e., upgrades) or when a customer hard resets / reformats their mobile device.

[0138]

[0168] The currency conversion system 104 can receive customer identity data and a request to restore the customer wallet from the customer device 102. In this example, the identity data may include the customer's name, date of birth, driver's license number and expiration date, address, telephone number, email address, social security number, image of the customer's government-issued photo ID, photograph of the customer holding the government-issued photo ID, employment information, and / or income. The identity data may also include biometric data such as fingerprint data (e.g., a scan of the customer's fingerprints), retinal scan data (e.g., an image of the customer's retina), facial recognition data (e.g., an image of the customer's face), and / or voice data (e.g., a recording of the customer's voice). Instead of raw biometric data (e.g., images and / or recordings), the identity data may include processed data derived from raw biometric data, such as image features, voice features, etc.

[0139]

[0169] The currency conversion system 104 receives the customer's identity from the customer device 102. The biometric data can be verified 904. For example, verification may include comparing the received biometric data with previously stored biometric data, for example, biometric data stored when the customer first created an account in the currency conversion system 104.

[0140]

[0170] Once the identity data received from the customer device is verified (i.e., the received biometric data matches previously stored biometric data), the currency conversion system 104 can identify one or more submitted multi-confirmation transaction addresses 530 in the customer wallet, i.e., one or more multi-confirmation transaction addresses 530 that contain cryptocurrency. This may involve traversing the multi-confirmation transaction addresses 530 associated with the private account key 214 stored in the currency conversion system 104 for the customer. Alternatively, the currency conversion system 104 can maintain an index of the last multi-confirmation transaction address 530 generated and / or submitted for the customer (associated with the private account key 214).

[0141]

[0171] The currency conversion system 104 can send a request to the key repository 116 for a trusted third party 106 to obtain one or more first secret transaction keys 226 associated with one or more submitted multi-confirmation transaction addresses 530. In other words, the currency conversion system 104 can request a secret transaction key 226 associated with a public transaction key 227 used to generate the submitted multi-confirmation transaction addresses 530. For example, this request may include an index on the trusted third party 106 for each requested first secret transaction key 226. For example, if the currency conversion system 104 requests three first secret transaction keys 226, the request may include three indices for the secret account keys 224 of the trusted third party 106. The first secret transaction keys 226 may be hardened keys generated during the purchase of cryptocurrency and / or previous cryptocurrency transactions (for storing the remaining cryptocurrency).

[0142]

[0172] The currency conversion system 104 may also receive one or more first secret transaction keys 226 associated with the customer wallet from a trusted third-party key repository 106 910. The currency conversion system 104 may also restore the customer wallet 912 using one or more first secret transaction keys 226 and one or more second secret transaction keys 216 associated with one or more submitted multi-confirmation transaction addresses 530. In this example, the second secret transaction key 216 may be stored in a node tree 200B on the currency conversion system 104 and may be associated with one or more multi-confirmation transaction addresses 530. The second secret transaction key 216 may be a hardened key generated during the purchase of cryptocurrency and / or previous cryptocurrency transactions (for storing the remaining cryptocurrency).

[0143]

[0173] Optionally, the currency conversion system 104 may also change its internal settings 914 to indicate that transaction requests from the customer's old customer device 102 should no longer be signed or executed.

[0144]

[0174] Figure 9C is a flowchart illustrating an exemplary method 900C for recovering a customer wallet after the loss of a customer's key component using key splitting. Method 900C may be performed by the currency conversion system 104 shown in Figure 1. Method 900C may be performed in response to a customer losing or destroying a device (e.g., a mobile device) that stored the key component of their customer wallet. Method 900C may be performed when a customer purchases a new mobile device (i.e., upgrades) or when a customer loses their mobile device This can also be done when hard resetting / reformatting the chair.

[0145]

[0175] The currency conversion system 104 can receive customer identity data and a request to restore the customer wallet from the customer device 102 916. In this example, the identity data may include the customer's name, date of birth, driver's license number and expiration date, address, telephone number, email address, social security number, image of the customer's government-issued photo ID, photograph of the customer holding the government-issued photo ID, employment information, and / or income. The identity data may also include biometric data such as fingerprint data (e.g., a scan of the customer's fingerprints), retinal scan data (e.g., an image of the customer's retina), facial recognition data (e.g., an image of the customer's face), and / or voice data (e.g., a recording of the customer's voice). Instead of raw biometric data (e.g., images and / or recordings), the identity data may include processed data derived from raw biometric data, such as image features, voice features, etc.

[0146]

[0176] The currency conversion system 104 can verify the customer's identity data received from the customer device 102 918. In this example, verification may include comparing the received biometric data with previously stored biometric data, for example, biometric data stored when the customer first created an account with the currency conversion system 104.

[0147]

[0177] Once the identity data received from the customer device is verified (i.e., the received biometric data matches previously stored biometric data), the currency conversion system 104 can identify one or more deposited transaction addresses 530 in the customer wallet, i.e., one or more multi-confirmation transaction addresses 530 containing cryptocurrency. This may involve traversing the transaction addresses 530 in the customer wallet. Alternatively, the currency conversion system 104 can maintain an index of the last transaction address 530 generated and / or deposited for the customer.

[0148]

[0178] The currency conversion system 104 can send a request 922 to a trusted third-party key repository 106 for one or more first private key components associated with one or more entered transaction addresses. In other words, the currency conversion system 104 can request a first private key component associated with the public key component used to generate the transaction address.

[0149]

[0179] The currency conversion system 104 can also receive one or more first key components associated with the customer wallet from a trusted third-party key repository 106 924. The currency conversion system 104 can also restore the customer wallet 926 using one or more first key components and one or more second key components associated with one or more transaction addresses 530. In this example, the second private key component may be generated during the purchase of the cryptocurrency and / or previous cryptocurrency transaction (to store the remaining cryptocurrency).

[0150]

[0180] Optionally, the currency conversion system 104 may also change its internal settings 928 to indicate that transaction requests from the customer's old customer device 102 should no longer be signed or executed.

[0151]

[0181] Figure 10A is a block diagram illustrating an exemplary method 100A for restoring a customer wallet using multisignature. Figure 10A shows one implementation of element 909 of Figure 9A. Method 1000A can be performed by one or more of the customer device 102, currency conversion system 104, and / or trusted third parties 106 shown in Figure 1.

[0152]

[0182] Method 1000A may be performed after the customer loses, destroys, upgrades, or hard resets / reformats the customer device 102 that possesses the private key associated with the customer wallet. The process of restoring the customer wallet (i.e., the old customer wallet) includes creating a new customer wallet and transferring assets from the old customer wallet to the new customer wallet.

[0153]

[0183] As used herein, the term “old” when referring to a key, address, or customer wallet means that the key, address, or wallet was created during onboarding (for example, as shown in Figure 3). The term “new” when referring to a key, address, or customer wallet means that the key, address, or wallet was created during account recovery following the loss of one or more old keys, addresses, or wallets.

[0154]

[0184] One or more new private keys may be generated 1001 associated with the new customer wallet. The new private keys may be generated for the customer device 102, the currency conversion system 104, and / or a trusted third party 106.

[0155]

[0185] One of the devices generating a new private key (for example, the currency conversion system 104) can also generate a new transaction address associated with a new customer wallet based on the new private key 1003. This may involve generating a new public key associated with the new private key, and deriving the new transaction address from the new public key. In the example, the hash function could receive three new public keys (for example, one each from the customer device 102, the currency conversion system 104, and a trusted third party 106) and generate a new transaction address. The device then needs to possess a new private key associated with at least two of the new public keys in order to execute a transaction from the new transaction address.

[0156]

[0186] Digital assets are also transferred from an old (lost) customer wallet to a new transaction address 1005, and the transaction can be signed using, for example, a first key (from a trusted third party 106) and a second key (from a currency conversion system 104). This involves the customer device 102, the currency conversion system 104, and / or the trusted third party 106 sending a request to the asset exchange 108 (or other node with access to the distributed ledger 118) to record the change of ownership from the old customer wallet to the new transaction address. The request to record the change of ownership may require a signature using the M / N of the new private key (e.g., 2 / 3) or the M / N of the old private key (e.g., 2 / 3). Therefore, the device generating or sending the request must verify that it already possesses one or more old private keys and / or has received one or more old private keys from another device before signing the request; in other words, the generating / sending device must verify that it possesses the M / N of the old private key (e.g., 2 / 3) before signing the request.

[0157]

[0187] The currency conversion system 104 can also communicate the new transaction address and one or more of the new private keys to the customer device 102. Optionally, the currency conversion system can transfer the new transaction address from the old customer wallet. The customer device 102 may also be notified 1009 when the transfer of digital assets to a user address is successfully recorded, for example, in the distributed ledger 118.

[0158]

[0188] Figure 10B is a block diagram showing another exemplary method 1000B for recovering a customer wallet using multisignature. Figure 10B shows one implementation of element 912 of Figure 9B. Method 1000B can be performed by one or more of the customer device 102, currency conversion system 104, and trusted third parties 106 shown in Figure 1.

[0159]

[0189] Method 1000B may be performed after the customer loses, destroys, upgrades, or hard resets / reformats the customer device 102 that holds the private key associated with the customer wallet. The process of restoring the customer wallet (i.e., the old customer wallet) may include transferring assets from the transaction address associated with the old account key to the transaction address associated with the new account key.

[0160]

[0190] Optionally, new public account keys 205, 215, and 225 can be generated for each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Method 1000B is likely to be performed after the loss of the customer's private account key 204 (and public account key 205) on the old customer device 102, so that the new customer device 102 can generate a new public account key 205 from, for example, a new private account key 204. The currency conversion system 104 can generate a new public account key 215 with a new index of the master public key 213 stored in the node tree 200B. The currency conversion system 104 can also use the master public key 223 stored in the currency conversion system 104 to generate a new public account key 225 for the trusted third party 106, for example, with a new index of the master public key 223 stored in the currency conversion system 104. A trusted third party 106 may share its master public key 223 with the currency conversion system 104 via secure and / or non-electronic means.

[0161]

[0191] A first index-zero public transaction key 207 for customer device 102, a second index-zero public transaction key 217 for currency conversion system 104, and a third index-zero public transaction key 227 can be determined 1004. In the example, one or more of the index-zero public transaction keys 207, 217, and 227 can be derived from index 0 of the new public account keys 205, 215, and 225, respectively. Alternatively, one or more of the index-zero public transaction keys 207, 217, and 227 can be derived from one or more new private account keys 204, 214, and 224, respectively. Alternatively, or furthermore, one or more Index Zero public transaction keys 207, 217, 227 may be derived from one or more Index Zero private transaction keys 206, 216, 226, respectively, which can be derived from one or more new private account keys 204, 214, 224. In other words, the Index Zero public transaction keys 207, 217, 227 may be derived via any path within their respective node trees 200A, 200B, 200C.

[0162]

[0192] The currency conversion system 104 can also generate a multi-approval transaction address 530 of index zero from the public transaction keys 207, 217, and 227 of index zero 1006. This involves using a hash function (e.g., pay-to-script hash (P2SH) or other public key script) to perform a transaction from the multi-approval transaction address 530 using two secret keys of index zero. This includes creating a multi-authorization transaction address 530 that requires transaction keys 206, 216, and 226.

[0163]

[0193] The currency conversion system 104 can also transfer cryptocurrency from one or more submitted multi-confirmation transaction addresses 530 to an index-zero multi-confirmation transaction address 530 using one or more first secret transaction keys 226 associated with a first old secret account key 204 and one or more second secret transaction keys 216 associated with a second old secret account key 214. In other words, the currency conversion system 104 can transfer cryptocurrency from multi-confirmation transaction addresses 530 associated with old secret account keys 204, 214, 224 and / or old public account keys 205, 215, 225 to an index-zero multi-confirmation transaction address associated with new public account keys 205, 215, 225.

[0164]

[0194] The currency conversion system 104 can also communicate to the customer device 102 the multi-approval transaction address 530 with index zero and the private transaction key 216 associated with the second public transaction key 217. Optionally, the currency conversion system 104 can also record the transfer to the distributed ledger and notify the customer device 102 when the transfer has been successfully recorded.

[0165]

[0195] Figure 10C is a block diagram illustrating exemplary method 1000C for recovering a customer wallet using key splitting. Figure 10C shows one implementation of element 926 in Figure 9B. Method 1000C can be performed by one or more of the customer device 102, currency conversion system 104, and trusted third parties 106 shown in Figure 1.

[0166]

[0196] Method 1000C may be performed after the customer loses, destroys, upgrades, or hard resets / reformats the customer device 102 that possesses the private key component associated with the customer wallet. The process of restoring the customer wallet (i.e., the old customer wallet) involves creating a new customer wallet and transferring assets from the old customer wallet to the new customer wallet.

[0167]

[0197] Optionally, a new public account key, for example, a new public account key 205, may be generated on customer device 102 1014. Since method 1000C is likely to be performed after the loss of the customer's private account key 204 (and public account key 205) on the old customer device 102, the new customer device 102 can generate a new public account key 205 from, for example, a new private account key 204.

[0168]

[0198] The public transaction key at index zero may be determined from the new public account key 1016. In the example, the public transaction key 207 at index zero may be derived from index 0 of the new public account key 205. Alternatively, the public transaction key 207 at index zero may be derived from the new private account key 204 on the customer device 102. Alternatively, the public transaction key 207 at index zero may be derived from the private transaction key 206 at index zero, which can be derived from the new private account key 204. In other words, the public transaction key 207 at index zero may be derived through any path in the node tree 200A.

[0169]

[0199] The transaction address of index zero can be generated from the public transaction key of index zero. This includes a hash function (for example, public This involves creating a transaction address that requires the secret transaction key 206 to perform transactions from the transaction address using a key script.

[0170]

[0200] One or more private transaction keys 206 can be reconstructed 1020 using one or more first private key components from a trusted third party 106 and one or more second private key components from the currency conversion system 104.

[0171]

[0201] The cryptocurrency from one or more deposited transaction addresses may be transferred to an index zero transaction address using the reconstructed private transaction key 206. In other words, the cryptocurrency from transaction addresses associated with the old private account key 204 and / or the old public account key 205 may be transferred to an index zero transaction address associated with the new public account key 205.

[0172]

[0202] The currency conversion system 104 also communicates to the customer device 102 1024 the transaction address 530 of index zero and one or more private key components associated with the public transaction key of index zero. Optionally, the transfer may be recorded in a distributed ledger and the customer device 102 may be notified 1026 when the transfer has been successfully recorded.

[0173]

[0203] Figure 11 is a block diagram showing an exemplary system 1100 for conducting transactions from a multi-approval transaction address 530. System 1100 may complement the currency conversion system 104 shown in Figure 5 and may conduct transactions from the multi-approval transaction address 530 using M out of N (e.g., 2 / 3) secret transaction keys 206A, 216A, 226A. System 1100 may be implemented on a customer device 102 or the currency conversion system 104, depending on the application.

[0174]

[0204] Specifically, in the case of a routine cryptocurrency transaction, system 1100 may be performed on customer device 102. In the example, system 1100 can receive a secret transaction key 216A from currency conversion system 104 (at index X of the customer's secret account key 214). System 1100 can input secret transaction key 216A and secret transaction key 206A (also at index X of the secret account key 204 on customer device 102) into redemption module 1140. Redemption module 1140 can verify that both secret transaction key 206A and secret transaction key 216A correspond to the same multi-confirmation transaction address 530. If both secret transaction key 206A and secret transaction key 216A correspond to the multi-confirmation transaction address 530, redemption module 1140 can generate a signed transaction 1142. In other words, system 1100 can enable cryptocurrency at multi-approval transaction address 530 to be transferred to another transaction address specified by the customer, for example, on customer device 102. The redemption module 1140 can generate a signed transaction 1142 using a redemption script (for example, according to BIP 16).

[0175]

[0205] Alternatively, in the case of cryptocurrency transactions related to the restoration of a customer wallet, system 1100 may perform the currency conversion in system 104. In this example, system 1100 receives the customer's private account key 224 from a trusted third party 106. The system 1100 can receive the secret transaction key 226A (at index Y). The system 1100 can input the secret transaction key 226A and the secret transaction key 216A (which is also at index Y of the secret account key 214 on the currency conversion system 104) into the redemption module 1140. The redemption module 1140 can verify that both the secret transaction key 216A and the secret transaction key 226A correspond to the same multi-confirmation transaction address 530. If both the secret transaction key 216A and the secret transaction key 226A correspond to the multi-confirmation transaction address 530, the redemption module 1140 can generate a signed transaction 1142, and for example, the system 1100 can allow the cryptocurrency at the multi-confirmation transaction address 530 to be transferred to the new multi-confirmation transaction address 530. The redemption module 1140 can generate the signed transaction 1142 using a redemption script (for example, according to BIP 16).

[0176]

[0206] Figure 12 is a block diagram showing another exemplary system 1200 for multi-confirmation cryptocurrency accounts and transactions. System 1200 may include a customer device 102, an optional asset exchange 108, an optional identity service provider 110, and an optional distributed ledger 118, each generally corresponding to the system / device in Figure 1. System 1200 may also include N vault systems 1250A-N and an optional record-keeping system 1252.

[0177]

[0207] Each of the vault system 1250 and the record-holding system 1252 may be implemented as a mobile computing device such as a mobile phone, tablet computer, mobile media device, mobile game device, laptop computer, or vehicle-based device, or as a non-mobile computing device such as a dedicated terminal, public terminal, kiosk, server, cloud server, or desktop computer. Each vault system 1250 and the record-holding system 1252 may include one or more computing devices in one or more housings. Each vault system 1250 and the record-holding system 1252 may include at least one processor that executes instructions stored in at least one memory.

[0178]

[0208] Each device in system 1200 may be communicably coupled to one or more other devices using at least one network 112 (e.g., networks 112A-B). In the example, at least one network 112 includes at least one wired network and / or at least one wireless network. In the example, any combination of wired and wireless networks can be used to couple the customer device 102, the vault system 1250, and the optional record-keeping system 1252. In the example, at least one network 112 includes at least one of at least one local area network (LAN), at least one wide area network (WAN), or the internet. In the example, any combination of local area networks, wide area networks, or the internet can be used as at least one network 112 to couple the customer device 102, the vault system 1250, and the optional record-keeping system 1252.

[0179]

[0209] System 1200 can use a multi-authorization methodology, such as a multi-party multi-signature (multisig) methodology, a multi-party key splitting methodology, or a combination of the two. When multisig is used, N private keys may be generated, for example, by the customer device 102, the vault system 1250, or some combination. Alternatively, when key splitting is used, the private keys may be generated by the customer device 102, or the vault system 1250. The private key is generated in one of the stems 1250, and then split into N key components, each stored in a different vault system 1250 or customer device 102. Alternatively, system 1200 may use a combination of multisig and key splitting methodologies, for example, in which N private keys are generated (in customer device 102 and / or vault system 1250), and at least one of the private keys is split into various key components that need to be reconstructed before being used to sign a transaction.

[0180]

[0210] In system 1200, customer device 102 encrypts / decrypts data, generates transaction addresses, sends completed transactions to record in an optional distributed ledger 118, generates sweep transactions during customer wallet recovery, and / or signs transactions. For example, customer device 102 in system 1200 can generate N private keys (or key components) and distribute them to the vault system 1250 for secure storage. Alternatively, customer device 102 in system 1200 can generate N private keys (or key components), distribute N-1 of them to each of the N-1 vault systems 1250, and store one of the private keys (or key components) locally, for example, in a key repository 111. The private keys may be hierarchical deterministic (HD) private keys, for example, the private account key 204 described above. Each private key can be indexed to a specific customer.

[0181]

[0211] During onboarding in the vault system 1250, the customer device 102 can transmit identity data (associated with the customer) to the vault system 1250 and / or the identity service provider 110. As described above, identity data may include personally identifiable information such as the customer's name, date of birth, driver's license number and expiration date, address, telephone number, email address, social security number, image of the customer's government-issued photo ID, photograph of the customer holding the government-issued photo ID, employment information, and / or income. Identity data may also include biometric data such as fingerprint data (e.g., a scan of the customer's fingerprints), retinal scan data (e.g., an image of the customer's retina), facial recognition data (e.g., an image of the customer's face), and / or voice data (e.g., a recording of the customer's voice). Instead of raw biometric data (e.g., images and recordings), the application may transmit only processed data derived from raw biometric data, such as image features, voice features, etc. In addition to identity data, the customer device 102 may also transmit a private key (or key component) for the vault system 1250 to store, for example, in its key repository.

[0182]

[0212] It should be noted that an alternative onboarding configuration is possible in which (1) the customer device 102 transmits identity data to the vault system 1250, and (2) the vault system 1250 generates a private key (or key component) associated with the customer device 102 (rather than receiving it from the customer device 102). Regardless of whether the vault system 1250 receives the private key (or key component) from the customer device 102 or generates the private key (or key component), the vault system 1250 can associate the private key (or key component) with the customer in the vault system 1250.

[0183]

[0213] Furthermore, the onboarding process executed between the customer device 102 and the Bolt system 102 may include recording a transaction indicating the generation and / or transmission of a private key (or key component). In an example, the customer device 102 or the Bolt system 1250 that generates the private key (or key component) may provide the hash of the private key (or key component) to the distributed ledger (or the nodes implementing the optional distributed ledger 118) as proof of the creation of the private key (or key component). In an example, a single transaction may serve as proof of the creation of all N private keys (or key components).

[0184]

[0214] Furthermore, the application programming interface (API) may be distributed between the customer device 102 and the Bolt system 1250. In an example, the customer device 102 can prompt for and receive user input specifying the number and which of the Bolt systems 1250 (and optionally, the customer device 102 itself) in which the customer wants to store their private key (or key component). In an example, the customer can select any number (e.g., N = 1 - 100) of Bolt systems 1250 to store the private key (or key component) and specify that all the private keys (or key components) are required to perform an action (e.g., encrypting and / or decrypting, signing a transaction, etc.), i.e., M = N. Alternatively, the customer can select any number (e.g., N = 1 - 100) of Bolt systems 1250 to store the private key (or key component) and specify that fewer keys than all the keys (or key components) are required to perform an action, i.e., M < N. Preferably, both M and N are greater than 1.

[0185]

[0215] Optionally, customers can adjust the configuration used based on security, reliability, cost, and / or other concerns. For example, a customer might require three out of four private keys (or key components) and use one of the four private keys (or key components) initially stored on the customer device 102 itself to perform actions on their personal account (e.g., (M=3) < (N=4)). Such a configuration can be used for accounts where the customer wishes to maintain a high degree of control, for example, because (1) more people would need to collude to steal funds from the account, and (2) all private keys (or key components) do not reside outside the customer device 102. In other words, a 3 / 4 configuration can reduce the likelihood of account funds being stolen (compared to, for example, a 2 / 4 or 2 / 5 configuration and / or a configuration where the private keys (or key components) are not initially stored on the customer device 102 itself).

[0186]

[0216] In another example, a customer might require two out of five private keys (or key components) to perform actions on their personal account (e.g., (M=2)<(N=5)). Such a configuration can be used if the customer is concerned about the loss of private keys (or key components) stored in the vault system 1252. In other words, a two-of-five configuration can increase reliability (compared to, for example, a 2 / 2 or 2 / 3 configuration) and reduce failover concerns associated with the loss of customer data.

[0187]

[0217] Furthermore, a customer may have multiple accounts, such as personal, business, and family accounts. Therefore, a customer can adjust digital security in different ways for two different accounts. For example, a customer may only need two out of three private keys (or key components) to perform an action in their personal account (e.g., (M=2) < (N=3)), while needing all four private keys (or key components) to perform an action in their business account (e.g., (M=4) = (N=4)). Additionally, a customer may initially choose to store one out of N private keys (or key components) on their customer device 102 for one account, while initially choosing not to store any of the N private keys (or key components) for another account.

[0188]

[0218] Therefore, as needed, customers can adjust / select specific storage locations for (1) M and / or N values ​​and / or (2) N private keys (or key components) based on security, reliability, cost, and / or other considerations.

[0189]

[0219] Once the customer selects the number and type of vault system 1250 (and optionally the customer device 102 itself) in which they wish to store N private keys (or key components), the customer device 102 can then communicate with the selected vault system 1250 (e.g., during and after onboarding) via the API. Furthermore, the customer device 102 and / or vault system 1250 can use the API to generate private keys (or key components) associated with the customer.

[0190]

[0220] An optional record-keeping system 1252 can store records of which vault system 1250 stores a given customer's private key (or key component). The record-keeping system 1252 may be located in the same location as one of the vault systems 1250. In the example, the record-keeping system 1252 may be located on a currency conversion system 104 which may or may not be a vault system 1250 that stores a customer's private key (or key component).

[0191]

[0221] System 1200 can include N vault systems 1250A to N, if N is 1 or greater. Each vault system 1250 can maintain key repositories 117A to N for storing keys associated with each customer (e.g., databases and / or secure memory). The key repository 117 of each vault system 1250 can be physically located on the same or different devices that perform other functions of each vault system 1250.

[0192]

[0222] Each vault system 1250 may be owned and / or operated by a different trusted third party 106 (e.g., a financial institution such as a credit union or bank), a currency conversion system 104 (e.g., a bank or a non-bank financial institution that converts currency into another form of currency), a corporation, an individual, etc. In this example, each vault system 1250 may send a private key (or key component) to the customer device 102 (upon request from the customer device 102) to generate a transaction address or wallet restore, but the vault systems 1250 preferably do not generate transaction addresses, sign transactions, or send transactions to the optional distributed ledger 118 itself. In such an example, the vault systems 1250 may not be required to hold a remittance license under applicable rules and regulations. However, alternatively, one or more vault systems 1250 can be configured to generate transaction addresses, sign transactions, send transactions, and / or hold a remittance license.

[0193]

[0223] After onboarding by at least one vault system 1250, a customer device 102 (for example, an API on the customer device 102) can send key requests for a private key (or key component) to one or more vault systems 1250. In one configuration, the customer device 102 can send key requests to multiple (e.g., N) vault systems 1250. Alternatively, for example, if the customer device 102 stores one of the private keys (or key components) locally, the customer device 102 can send requests to N-1 vault systems 1250. In the example, a vault system 1250 may charge the customer device 102 a fixed amount for storing and / or sending the private key (or key component) to the customer device 102.

[0194]

[0224] The vault system 1250 and / or the identity service provider 110 can use an authentication protocol to identify the customer submitting the key request. In the first authentication configuration, the vault system 1250 directly stores the identity data. In this configuration, each key request also includes identity data that each vault system 1250 can use to identify the private key (or key component) associated with the requesting customer. Once the customer's identity data has been verified and the private key (or key component) has been identified, the vault system 1250 can send the identified private key (or key component) to the customer device 102.

[0195]

[0225] In the second authentication configuration, the identity service provider 110 (instead of the vault system 1250) can store the customer's identity data. Since the vault system 1250 does not perform authentication, does not perform AML / KYC for the customer, and does not store the customer's identity data, the second configuration may be preferable to the first configuration. Optionally, the customer wallet provider can perform AML / KYC for the customer.

[0196]

[0226] In the second authentication configuration, each key request sent by the customer device 102 may have a corresponding identity request containing identity data (and sent to the identity service provider 110). Upon receiving the identity request from the customer device 102, the identity service provider 110 authenticates the customer based on the identity data in the identity request, and can then send some information (e.g., customer ID) to the vault system 1250. In the example, the identity service provider 110 may send an authentication success message indicating that the customer has been authenticated by the identity service provider 110. In response to receiving the customer ID and / or the authentication success message, the vault system 1250 can send the private key (or key component) associated with the customer to the customer device 102.

[0197]

[0227] If a customer device possesses at least M private keys (or key components) out of N, then customer device 102 can perform at least one action based on (for example, requiring) at least M private keys (or key components) out of N. Examples of such actions include (1) encrypting or decrypting data using the M private keys (or key components), (2) generating a transaction address based on the N private keys (or key components), and / or (3) using the M private keys (or key components) to sign a transaction, such as a sweep transaction during customer wallet restoration. In a key-splitting configuration, the action would include customer device 102 reconstructing a private key from at least M (or N) private key components. Furthermore, although at least M private keys (or key components) may not be required, customer device 102 may also generate a sweep transaction during customer wallet restoration and / or send the transaction to an optional distributed ledger 118, for example, a node implementing the optional distributed ledger 118.

[0198]

[0228] In a configuration where data is encrypted or decrypted using a private key (or key component), the customer device 102 and / or at least one vault system 1250 can generate N private keys (or key components). In a multi-signature configuration, N private keys can be generated by the customer device 102 and / or at least one vault system 1250. In a key-splitting configuration, a single private key is generated (on the customer device 102 or at least one vault system 1250) and split into N private key components. Each of these can be distributed to at least one vault system 1250 and / or different versions of the customer device 102 itself, for example, during an onboarding process performed between different vault systems 1250 and customer devices 102. The customer device 102 can then request and receive at least M of the N private keys (or key components), and for example, M private keys (or key components) can be sent from at least one vault system 1250 after authentication. Optionally, the customer device 102 can store one of the N private keys (or key components) locally and distribute only N-1 private keys (or key components) to each of the N-1 vault systems 1250.

[0199]

[0229] Authentication between each vault system 1250 and computing device 102 may be performed according to one of the configurations described above. In the example, the vault system 1250 may directly store identity data, and each key request may include identity data that each vault system 1250 can use to identify the private key (or key component) associated with the requesting customer. Alternatively, the identity service provider 110 (instead of the vault system 1250) may store the customer's identity data, and the identity service provider 110 may send an authentication indication to the vault system 1250 based on the authentication process performed between the identity service provider 110 and the customer device 102.

[0200]

[0230] If customer device 102 possesses at least M of N private keys (or key components), customer device 102 can identify the data to be encrypted and / or decrypted, for example, based on user input and / or previous display. Then, customer device 102 can encrypt and / or decrypt the data using at least M of N private keys (or key components).

[0201]

[0231] In the multisig example, data encryption may require all N secret keys (or N keys derived from N secret keys), while data decryption may require only M secret keys (or M keys derived from M secret keys). In the key splitting example, customer device 102 can reconstruct a single secret key from at least M of the N key components before encrypting and / or decrypting data using the reconstructed secret key.

[0202]

[0232] In the example, the data to be encrypted and / or decrypted could be non-monetary cryptographic tokens (e.g., related to customer identity data), security tokens (e.g., representing ownership of assets), audio files, video files, text files, or any other digital objects, files, and / or tokens. In the example, encryption and / or decryption could be part of a federated service in which the vault system 1250 receives a fee for storing each customer's private key (or key component) and / or sending the private key (or key component) to the customer. Optionally, the customer device 102 may delete at least one (e.g., all) of the locally stored private keys (or key components) after the data has been encrypted and / or decrypted.

[0203]

[0233] In a configuration where a private key (or key component) is used to generate transaction addresses based on N private keys (or key components), customer device 102 and / or at least one vault system 1250 can generate N private keys (or key components) and distribute them to customer device 102 and / or at least one vault system 1250. In a key-partition configuration, customer Device 102 can split a single private key into N private key components before distribution. Optionally, customer device 102 can store one of the N private keys (or key components) locally and distribute only N-1 private keys (or key components) to each of the N-1 vault systems 1250.

[0204]

[0234] In the multisig example, customer device 102 can generate a transaction address after obtaining or deriving N public transaction keys (or key components). In the multisig example, each public transaction key can be derived from each of the N private keys (or key components), and each public transaction key is derived (1) directly from a private account key received from the vault system 1250 or stored locally on customer device 102, and / or (2) from a public account key derived from a private account key received from the vault system 1250 or stored locally on customer device 102. As described above, receiving a private key from the vault system 1250 may involve direct authentication (between customer device 102 and the vault system 1250) or indirect authentication (performed via the identity service provider 110). Generating a transaction address may involve using a multi-authorization hash module 528 operating on the customer device 102, for example, using a pay-to-script hash (P2SH) as defined in BIP16, or other public key scripts as described in relation to Figure 5. In addition to the public transaction key, the multi-authorization hash module 528 may optionally receive a multi-authorization condition 529 specifying, for example, that M of N private keys are required to sign the transaction from the generated transaction address. The N public transaction keys (along with the multi-authorization condition 529) can then be used as input to the multi-authorization hash module 528 to generate a transaction address.

[0205]

[0235] In the key splitting example, the public transaction key may be derived from a single private key reconstructed from M (or N) private key components. After the public transaction key is derived, a transaction address can be generated based on the public transaction key.

[0206]

[0236] After a transaction address is generated, funds can be received using the generated transaction address. At that point, the customer device 102 can send a sweep transaction to the optional distributed ledger 118 (or one of the nodes implementing the optional distributed ledger 118) for recording in the optional distributed ledger 118.

[0207]

[0237] In a configuration where a private key (or key component) is used to sign transactions using M private keys (or key components), the customer device 102 and / or at least one vault system 1250 generate N private keys (or key components) and distribute them to the customer device 102 and / or at least one vault system 1250. In a key-splitting configuration, the customer device 102 can split a single private key into N private key components before distribution. After onboarding processes performed between different vault systems 1250 and the customer device 102, the customer device 102 may receive at least M of the N private keys (or key components), including, for example, direct authentication processes (between the customer device 102 and the vault system 1250) or indirect authentication processes (performed via the identity service provider 110). Optionally, customer device 102 can locally store one of N private keys (or key components), and only N-1 private keys (or key components) in each of the N-1 vault systems 1. Distribute to 250.

[0208]

[0238] In the multi-signature example, if customer device 102 possesses M of the required N private keys, it can sign transactions from transaction addresses that require M of the N private keys. Signing a transaction may involve using a redemption module 1140 operating on customer device 102. In the example, the redemption module can utilize a redemption script (for example, according to BIP16) to generate a signed transaction 1142, for example, as described in relation to Figure 11. In the example, each private transaction key can be derived from each of the M private account keys (or key components), and each private transaction key is derived from the respective private account key received from the vault system 1250 and optionally stored locally on customer device 102. The M private transaction keys (along with the transaction address) may be used as input to the redemption module 1140 to generate a signed transaction. In the key splitting example, a private transaction key can be derived from a single private account key reconstructed from M private key components out of N, and then a signed transaction can be generated based on the private transaction key and the transaction address.

[0209]

[0239] In the example, customer device 102 can sign a sweep transaction to restore a customer account or wallet after, for example, customer device 102 is lost, damaged, upgraded, or hard reset / reformatted. The sweep transaction may transfer all funds from at least one transaction address in the customer wallet (e.g., at least one unused transaction output (UTXO)) to a new transaction address. In the first example, customer device 102 can generate and sign a sweep transaction using at least M private keys (or private keys reconstructed from at least M key components). Customer device 102 can send the fully signed sweep transaction to the optional distributed ledger 118 (or one of the nodes implementing the optional distributed ledger 118) for recording in the optional distributed ledger 118.

[0210]

[0240] In the second example, (1) customer device 102 requests an external entity (e.g., vault system 1250 and / or currency conversion system 104) to generate a sweep transaction; (2) the external entity generates and optionally signs the sweep transaction; (3) the external entity sends the sweep transaction to customer device 102 and optionally signs it; (4) customer device 102 repeatedly sends the sweep transaction to different vault systems 1250 for signing (and receives the transaction from each vault system 1250) until the sweep transaction is signed by at least M of N private keys; and (5) customer device 102 sends the fully signed sweep transaction to the optional distributed ledger 118 (or one of the nodes implementing the optional distributed ledger 118) for recording in the optional distributed ledger 118.

[0211]

[0241] Figure 13 is a flowchart illustrating an exemplary method 1300 for performing actions based on at least M private keys (or key components) out of N, such as encrypting and / or decrypting data, generating transaction addresses, signing transactions, etc. Method 1300 may be performed by a customer device 102 and / or at least one vault system 1250 within system 1200 in Figure 12.

[0212]

[0242] Optionally, each of the multiple vault systems 1250 determines one of the N private keys (or key components) associated with the customer wallet 130 2. Each of the N private keys (or key components) can be generated in the customer device 102 and / or in each of the vault systems 1250. If generated in the customer device 102, each of the multiple vault systems 1250 can receive its respective private key (or key component) from the customer device 102, for example, during its respective onboarding process. Optionally, the customer device 102 can store one of the N private keys (or key components) locally and distribute only N-1 private keys (or key components) to each of the N-1 vault systems 1250. Alternatively, each of the N private keys (or key components) may be stored in one of the N different vault systems 1250. Thus, N or N-1 private keys (or key components) can be stored in the vault system 1250 for secure storage.

[0213]

[0243] In the example, a transaction indicating the generation and / or transmission of a private key (or key component) may be recorded (or transmitted for recording) to an optional distributed ledger 118 by the device / system generating the private key (or key component). In the example, the customer device 102 or vault system 1250 generating the private key (or key component) may send a hash of the private key (or key component) to the distributed ledger (or the node implementing the optional distributed ledger 118) to serve as proof of creation of the private key (or key component). In the example, a single transaction may serve as proof of creation of all N private keys (or key components).

[0214]

[0244] Optionally, the customer device 102 can send a request 1304 for the customer's identity data and its respective private key (or key component). In the first authentication configuration, the vault system 1250 stores the identity data directly. In the first authentication configuration, each key request may also include identity data that each vault system 1250 can use for the customer. In the second configuration, the customer device 102 can send the identity data to the identity service provider 110 (instead of the vault system 1250) for authentication, and the identity service provider 110 can then communicate with the vault system 1250. The identity data and / or key requests can be transferred using a secure transport protocol.

[0215]

[0245] Optionally, the customer may be authenticated 1306 based on identity data. In the first authentication configuration, the vault system 1250 stores the customer's identity data during onboarding and then compares it with the customer's received identity data. In the second authentication configuration, the identity service provider 110 can compare the received identity data with previously stored identity data and notify the vault system 1250 whether the customer has been authenticated or not.

[0216]

[0246] The customer device 102 can also receive its respective private key (or key component) from each of the multiple vault systems 1250, for example, using a secure transfer protocol. In configurations requiring customer authentication, each vault system 1250 can only transmit its respective private key (or key component) if authentication is successful.

[0217]

[0247] The customer device 102 can also perform at least one action 1310 based on at least M of the N private keys (or key components). In the example, the action may be based on at least M of the N private keys (or key components), and / or at least M of the N private keys (or key components). At least M keys are required out of the N keys derived from [the given set]. Examples of this action may include (1) encrypting or decrypting data using M private keys (or key components), (2) generating a transaction address based on N private keys (or key components), and / or (3) signing a transaction, for example, a sweep transaction during customer wallet recovery, using at least M private keys (or key components) out of N. These actions are described in detail below.

[0218]

[0248] In a key-splitting configuration, the action may include a customer device 102 reconstructing a private key from at least M private key components. Furthermore, although M private keys (or key components) may not be required, the customer device 102 may also generate a sweep transaction during customer wallet restoration and / or send the transaction to an optional distributed ledger 118, for example, to a node implementing the optional distributed ledger 118.

[0219]

[0249] Figure 14 is a flowchart illustrating an exemplary method 1400 for encrypting or decrypting data based on at least M private keys (or key components) out of N. Method 1400 can be performed by at least a customer device 102 within the system 1200 in Figure 12. Method 1400 may be an example of the action performed in step 1310 of method 1300 shown in Figure 13.

[0220]

[0250] The customer device 102 may first identify the data to be encrypted and / or decrypted 1404. Identifying the data may include the customer device 102 receiving user input indicating the data and / or utilizing a previous representation of the data to be encrypted and / or decrypted. Furthermore, any suitable method for identifying the data may be utilized.

[0221]

[0251] Next, the customer device 102 can encrypt or decrypt the identified data 1404 based on at least M of the N secret keys (or key components). In a multisig configuration, this may include encrypting or decrypting the data using at least M secret keys (at least one of which is received from the vault system 1250), or at least M keys derived from each of the M secret keys. In a multisig configuration, all N secret keys (or N keys derived from the N secret keys) may be required for data encryption, and only M secret keys (or M keys derived from the M secret keys) may be required for data decryption. In a key-splitting configuration, the customer device 102 can reconstruct a single secret key from at least M key components (at least one of which is received from the vault system 1250) before encrypting and / or decrypting the data using the reconstructed secret key.

[0222]

[0252] Optionally, customer device 102 may also delete at least one private key (or key component).1406 In this example, customer device 102 can only delete private keys (or key components) received from vault system 1250, but cannot delete, for example, private keys (or key components) that were optionally initially stored in customer device 102.

[0223]

[0253] Figure 15 is a flowchart illustrating an exemplary method 1500 for generating a transaction address on a customer device 102. Method 1500 can be performed by at least the customer device 102 within the system 1200 in Figure 12. Method 1500 may be an example of the action performed in step 1310 of method 1300 shown in Figure 13.

[0224]

[0254] Optionally, the customer device 102 can determine at least M of the N private keys (or key components). This includes receiving at least a portion of the N private keys (or key components) from each vault system 1250, and optionally identifying locally stored private keys (or key components) that were not previously stored in the vault system 1250. Alternatively, all N private keys (or key components) may be stored across the entire vault system 1250, for example, one private key (or key component) per vault system 1250.

[0225]

[0255] The customer device 102 may also generate a transaction address 1504 based on at least M private keys (or key components). In the multisig example, a different public transaction key can be derived from each of the N private keys. Generating a transaction address may involve using a multi-authorization hash module 528 running on the customer device 102, for example, utilizing pay-to-script hashing (P2SH) as defined in BIP16, or other public key scripts as described in relation to Figure 5. Optionally, a multi-authorization condition 529 can be specified, for example, specifying that at least M of the N private keys are required to sign a transaction from the generated transaction address. The transaction address can then be generated by using the N public transaction keys (along with the optional multi-authorization condition 529) as input to the multi-authorization hash module 528. In the multisig example, at least M of the N private keys may be required to later execute a transaction from the generated transaction address. M and / or N may be selected based on user input on the customer device 102. In the example, M <NまたはM=Nである。

[0226]

[0256] In the key splitting example, a single private key can be reconstructed from at least M private key components, and a public transaction key can be derived from the reconstructed private key. The public transaction key can then be used as input (for example, to a hash module) to generate a transaction address, for example, without multi-approval conditions. In the example, only the reconstructed private key may be required for a transaction from the generated transaction address.

[0227]

[0257] Optionally, customer device 102 may also receive funds to the transaction address 1506 as part of the transaction. Optionally, customer device 102 may also send completed transactions to an optional distributed ledger 118 for recording. More specifically, customer device 102 may send completed transactions to a node implementing the optional distributed ledger 118 for recording in the optional distributed ledger 118. Optionally, this may include a small fee paid by the customer to the node implementing the optional distributed ledger 118.

[0228]

[0258] Figure 16A is a flowchart illustrating an exemplary method 1600A for signing a transaction using at least M private keys (or key components) out of N. Method 1600A may be performed by at least customer devices 102 (and optionally at least one vault system 1250) within system 1200 in Figure 12. Method 1600A may be an example of the action performed in step 1310 of method 1300 shown in Figure 13.

[0229]

[0259] Optionally, the customer device 102 can determine at least M of the N private keys (or key components) 1602. This includes each ball The process may include receiving at least M of the N private keys (or key components) from the vault system 1250, and optionally identifying locally stored private keys (or key components) that were not previously stored in the vault system 1250. Alternatively, all N private keys (or key components) may be stored throughout the entire vault system 1250, for example, one private key (or key component) per vault system 1250.

[0230]

[0260] The customer device 102 can generate a transaction 1604. A transaction may include at least one input address, at least one output address, a timestamp, the amount of assets to be transferred, and / or a description of the assets to be transferred. The transaction transfers cryptocurrency from at least one generated transaction address. Alternatively, the transaction may represent the movement of assets via security tokens. Alternatively, the transaction may be a sweep transaction that transfers all funds from at least one transaction address in the customer wallet (e.g., at least one unused transaction output) to a new transaction address. A sweep transaction can be used to recover a customer's account or wallet, for example, after the customer device 102 is lost, damaged, upgraded, or hard reset / reformatted.

[0231]

[0261] A transaction may also be signed using at least M of N private keys (or key components). In the first signing configuration, the customer device 102 can sign a transaction using at least M of N private keys (or key components) received from each vault system 1250, and optionally, locally stored private keys (or key components) that were not previously stored in the vault system 1250. Signing a transaction may involve using a redemption module 1140 running on the customer device 102. In the example, the redemption module may utilize a redemption script (for example, according to BIP 16) to generate a signed transaction 1142, for example, as described in relation to Figure 11. In the multisig example, each private transaction key is derived from each of the at least M of N private account keys received from the vault system 1250 and optionally stored locally on the customer device 102. A signed transaction can be generated by using at least M private transaction keys (along with transaction addresses) out of N as input to the redemption module 1140. In the key splitting example, a private transaction key can be derived from a single private account key reconstructed from at least M private key components out of N, and then a signed transaction can be generated based on the private transaction key and transaction address.

[0232]

[0262] In the second signing configuration, the customer device 102 can repeatedly send the generated transaction to different vault systems 1250 (and receive the transaction from each vault system 1250) for signing until the generated transaction is signed with at least M of the N private keys.

[0233]

[0263] Optionally, customer device 102 can send a (fully signed) transaction to a receiving device, for example, a device that will receive funds as part of the transaction 1608. If the transaction is a sweep transaction, customer device 102 can instead send the sweep transaction to an optional distributed ledger 118 (for example, a node implementing the optional distributed ledger 118) for recording in the optional distributed ledger 118.

[0234]

[0264] Figure 16B is a flowchart illustrating exemplary method 1608B for signing a transaction using at least M private keys (or key components) out of N. Method 1600B may be performed by at least customer device 102 (and optionally at least one vault system 1250) within system 1200 in Figure 12. Method 1600B may be an example of the action performed in step 1310 of method 1300 shown in Figure 13.

[0235]

[0265] The customer device 102 can send a request to an external device 1612 to generate a transaction. The external device may be a vault system 1250 and / or a currency conversion system 104. The request may include at least one input transaction address, at least one output transaction address, a timestamp, the amount of assets to be transferred, and / or a description of the assets to be transferred.

[0236]

[0266] The customer device 102 can receive transactions 1614 from an external device. A transaction includes at least one input address, at least one output address, a timestamp, the amount of assets to be transferred, and / or a description of the assets to be transferred. A transaction can send funds from at least one generated transaction address. Alternatively, a transaction may represent the movement of assets via a security token. Alternatively, a transaction may be a sweep transaction that sends all funds from at least one transaction address in the customer wallet (e.g., at least one unused transaction output) to a new transaction address. A sweep transaction can be used to recover a customer's account or wallet, for example, after the customer device 102 is lost, damaged, upgraded, or hard reset / reformatted.

[0237]

[0267] A transaction can also be signed using at least M private keys (or key components) out of N. In the first signing configuration, the customer device 102 can sign a transaction using private keys (or key components) received from each vault system 1250, and optionally, locally stored private keys (or key components) that were not previously stored in the vault system 1250. Signing a transaction may involve using a redemption module 1140 operating on the customer device 102. In the example, the redemption module can utilize a redemption script (for example, according to BIP 16) to generate a signed transaction 1142, for example, as described in relation to Figure 11. In the multi-signature example, each private transaction key is derived from each of at least M private account keys out of N received from the vault system 1250 and optionally stored locally on the customer device 102. At least M private transaction keys (along with transaction addresses) out of N can be used as input to the redemption module 1140 to generate a signed transaction. In the key splitting example, a private transaction key can be derived from a single private account key reconstructed from at least M of the N private key components, and then a signed transaction can be generated based on the private transaction key and transaction address.

[0238]

[0268] In the second signing configuration, the customer device 102 can repeatedly send the generated transaction to different vault systems 1250 (and receive the transaction from each vault system 1250) for signing until the generated transaction is signed with at least M of the N private keys. In the example, the customer device 102 sends the transaction to the first vault system 1250 for signing, and receives it from the first vault system 1250 (signed by the first vault system 1250). The system receives the named transaction, then sends the transaction to the second vault system 1250, and receives the transaction (signed by the second vault system 1250) from the second vault system 1250, etc. Optionally, the external device generating the transaction (e.g., vault system 1250) may sign the transaction using a private key (or key component) before sending the transaction to the customer device 102. Also, optionally, the customer device 102 may sign the transaction using a locally stored private key (or key component) that was not previously stored in vault system 1250.

[0239]

[0269] Optionally, customer device 102 may send the (fully signed) transaction to a receiving device 1618, such as a device that receives funds as part of the transaction. If the transaction is a sweep transaction, customer device 102 may instead send the sweep transaction to an optional distributed ledger 118 (for example, a node implementing the optional distributed ledger 118) for recording in the optional distributed ledger 118.

[0240]

[0270] Figure 16C is a flowchart illustrating an exemplary method 1600C for signing a sweep transaction using at least M private keys (or key components) out of N on a customer device 102. Method 1600C may be performed by at least the customer device 102 within the system 1200 in Figure 12. Method 1600C may be an example of the action performed in step 1310 of method 1300 shown in Figure 13.

[0241]

[0271] Optionally, the customer device 102 may determine at least M of the N private keys (or key components). This includes receiving at least a portion of the N private keys (or key components) from each vault system 1250 and optionally identifying locally stored private keys (or key components) that were not previously stored in the vault system 1250. Alternatively, all N private keys (or key components) may be stored across the entire vault system 1250, for example, one private key (or key component) per vault system 1250.

[0242]

[0272] The customer device 102 may, for example, generate a sweep transaction 1624 that transfers all funds from at least one transaction address in the customer wallet (e.g., at least one unused transaction output) to a new transaction address. The sweep transaction can be used to recover the customer's account or wallet, for example, after the customer device 102 is lost, damaged, upgraded, or hard reset / reformatted.

[0243]

[0273] A sweep transaction can also be signed using at least M private keys (or key components) out of N. In the example, customer device 102 can sign a sweep transaction using at least one private key (or key component) received from each vault system 1250, and optionally, locally stored private keys (or key components) that were not previously stored in the vault system 1250. Signing a sweep transaction may involve using a redemption module 1140 running on customer device 102. In the example, the redemption module can utilize a redemption script (for example, according to BIP 16) to generate a signed sweep transaction 1142, for example, as described in relation to Figure 11. In the multisig example, each private transaction key is one of N received from the vault system 1250. At least M private account keys are derived from each of them and optionally stored locally on the customer device 102. At least M of the N private transaction keys (along with the transaction address) can be used as input to the redemption module 1140 to generate a signed sweep transaction. In the key splitting example, the private transaction key can be derived from a single private account key reconstructed from at least M of the N private key components, and then a signed sweep transaction can be generated based on the private transaction key and the transaction address.

[0244]

[0274] Optionally, the customer device 102 may send a sweep transaction to the optional distributed ledger 118 (for example, a node implementing the optional distributed ledger 118) 1628 for recording in the optional distributed ledger 118.

[0245]

[0275] In the examples, the devices and systems described herein are implemented using memory and / or a processor. In the examples, memory can be any device, mechanism, or inserted data structure used to store information. In the examples, memory can be or include any type of volatile memory, non-volatile memory, and / or dynamic memory. In the examples, memory can be random access memory, memory storage devices, optical memory devices, magnetic media, floppy disks, magnetic tapes, hard drives, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), optical media (such as compact discs, DVDs, Blu-ray discs, etc.). According to some embodiments, memory can include one or more disk drives, flash drives, one or more databases, one or more tables, one or more files, local cache memory, processor cache memory, relational databases, flat databases, etc. Furthermore, those skilled in the art will understand many additional devices and techniques for storing information that can be used as memory. Memory can be used to store instructions for running one or more applications or modules on a processor. In the examples, memory may be used in one or more examples to contain all or some of the instructions necessary to perform any of the functions of the system devices described herein. The processor may be a general-purpose processor (GPP), a known processor such as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other integrated circuit or circuit configuration, or any programmable logic device.

[0246]

[0276] The techniques described herein can be embodied as dedicated hardware (such as circuit configurations), as programmable circuit configurations appropriately programmed with software and / or firmware, or as a combination of dedicated and programmable circuit configurations. Therefore, embodiments may include machine-readable media containing instructions that can be used to program a computer (or other electronic device) to perform operations. Machine-readable media may include, for example, floppy disks, optical disks, compact disk read-only memory (CD-ROM), magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or other types of media / machine-readable media suitable for storing electronic instructions.

[0247] Computer System Overview

[0277] Embodiments of this disclosure include the various steps and operations described above. These various steps and operations are performed by hardware components or These steps are embodied in machine-executable instructions used to cause a general-purpose or dedicated processor programmed with instructions to perform the steps. Alternatively, these steps may be performed by a combination of hardware, software, and / or firmware. Thus, Figure 17 is a block diagram showing an exemplary computer system 1700 from which embodiments of the present disclosure can be utilized. According to this example, the computer system 1700 includes an interconnect 1702, at least one processor 1704, at least one communication port 1706, at least one main memory 1708, at least one removable storage medium 1710, at least one read-only memory 1712, and at least one mass storage device 1714.

[0248]

[0278] At least one processor 1704 can be any known processor. At least one communication port 1706 can be, or include, an RS-232 port for use with a modem-based dial-up connection, a 10 / 100 Ethernet port, or a Gigabit port using copper or fiber. The nature of at least one communication port 1706 can be selected depending on the network to which the computer system 1700 is connected, such as a local area network (LAN), a wide area network (WAN), or any other network to which the computer system 1700 is connected. At least one main memory 1708 can be random access memory (RAM) or any other dynamic storage device commonly known in the art. At least one read-only memory 1712 can be any static storage device, such as a programmable read-only memory (PROM) chip, for storing static information, such as instructions for at least one processor 1704.

[0249]

[0279] At least one large-capacity storage device 1714 can be used to store information and instructions. For example, a hard disk (such as a magnetic disk drive or a solid-state drive using a serial / parallel ATA or SCSI interface), an optical disk, an array of disks such as a redundant array of independent disks (RAID), or other large-capacity storage devices can be used. The interconnect 1702 can be, or can include, one or more buses, bridges, controllers, adapters, and / or point-to-point connections. The interconnect 1702 communicatively couples at least one processor 1704 to other memory, storage, and communication blocks. The interconnect 1702 can be a PCI / PCI-X or SCSI-based system bus depending on the storage device used. At least one removable storage medium 1710 can be any type of external hard drive, floppy drive, compact disc read-only memory (CD-ROM), compact disc rewritable (CD-RW), digital video disc read-only memory (DVD-ROM), Blu-ray disc read-only memory (BD-ROM), Blu-ray disc writable (BD-R), Blu-ray disc writable erasable (BD-RE).

[0250]

[0280] The above components are intended to illustrate some types of possibilities. Since the foregoing examples are merely exemplary embodiments, they should in no way limit the present disclosure.

[0251]

[0281] FIG. 18 is a block diagram showing another exemplary computing device 1800. The exemplary computing device 1800 can be used to implement any of the customer device 102, the currency conversion system 104, the trusted third party 106, the asset exchange 108, the identity service provider 110, the Bolt system 1250, and / or the optional record-keeping system 1252. The computing device 1800 includes at least one memory 1802, at least one processor 1804, an optional at least one network interface 1806, an optional display device 1808, an optional input device 1810, and an optional power supply 1812.

[0252]

[0282] In an example, at least one memory 1802 can be any device, mechanism, or input data structure used to store information. In an example, at least one memory 1802 can be or can include any type of volatile memory, non-volatile memory, and / or dynamic memory. In an example, at least one memory 1802 can be a random access memory, a memory storage device, an optical memory device, a magnetic medium, a floppy disk, a magnetic tape, a hard drive, an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), an optical medium (compact disk, DVD, Blu-ray disk, etc.).

[0253]

[0283] According to some embodiments, at least one memory 1802 may include one or more disk drives, flash drives, one or more databases, one or more tables, one or more files, local cache memory, processor cache memory, relational databases, flat databases, and the like. Furthermore, those skilled in the art will understand many additional devices and techniques for storing information that can be used as at least one memory 1802. At least one memory 1802 may be used to store instructions for running one or more applications or modules on at least one processor 1804. In examples, at least one memory 1802 may be used in one or more examples to accommodate all or some of the instructions necessary to perform the functions discussed herein, for example, in Figures 3-4 and 6-10.

[0254]

[0284] At least one processor 1804 may be a general-purpose processor (GPP), a known processor such as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other integrated circuit or circuit configuration, or any programmable logic device. For example, any of the functions disclosed herein (for example, in Figures 3–4, 6–10, and 13–16C) may be performed by at least one processor 1804 and at least one memory 1802.

[0255]

[0285] In the example, at least one optional network interface 1806 includes or is coupled to at least one optional antenna for communicating with a network (such as one of the at least one network 112 of system 100). In the example, at least one optional network interface 1806 includes at least one of the following: Ethernet interface, Cellular Radio Access Technology (RAT) radio, Wi-Fi radio, Bluetooth® radio, or Near Field Communication (NFC) radio. In the example, at least one optional network interface 1806 includes a Cellular Radio Access Technology radio configured to establish a sufficiently fast cellular data connection (mobile internet) with a remote server using a local area network (LAN) or wide area network (WAN). Examples of cellular wireless access technologies include Personal Communications Services (PCS), Specialized Mobile Radio (SMR) services, Enhanced Specialized Mobile Radio (ESMR) services, Advanced Wireless Services (AWS), Code Division Multiple Access (CDMA), Global Mobile Communication System (GSM) services, Wideband Code Division Multiple Access (W-CDMA), Universal Mobile Telecommunications System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX), 3G Partnership Programme (3GPP) Long-Term Evolution (LTE), High-Speed ​​Packet Access (HSPA), 3G, 4G, 5G, and other suitable technologies. Includes at least one of the following communication services, or a combination thereof. In the example, at least one optional network interface 1806 includes a Wi-Fi (IEEE 802.11) radio configured to communicate with a wireless local area network that communicates with a remote server, rather than a wide area network. In the example, at least one optional network interface 1806 includes a near-field communication device limited to neighbor communication, such as a passive near-field communication (NFC) tag, an active near-field communication (NFC) tag, a passive radio frequency identification (RFID) tag, an active radio frequency identification (RFID) tag, a proximity card, or other personal area network device. Includes.

[0256]

[0286] In the example, at least one optional display device 1808 includes light-emitting diodes (LEDs), liquid crystal displays (LCDs), LED displays, organic light-emitting diode (OLED) displays, e-ink displays, field emission displays (FEDs), surface conduction electron emission displays (SEDs), or plasma displays. In the example, at least one optional input device 1810 includes at least one of the following: touchscreens (including capacitive and resistive touchscreens), touchpads, capacitive buttons, mechanical buttons, switches, dials, keyboards, mice, cameras, biometric sensors / scanners, microphones, etc. In the example, at least one optional display device 1808, combined with at least one optional input device 1810, forms a human-machine interface (HMI) for user interaction with customer device 102, currency conversion system 104, and / or trusted third party 106. In the example, at least one optional power supply 1812 is used to power various components of computing device 1800.

[0257] term

[0287] The following are brief definitions of terms, abbreviations, and phrases used throughout this application.

[0258]

[0288] The term "decide" can include calculating, computing, generating, processing, deriving, investigating, looking up (e.g., looking up a table, database, or other data structure), and confirming. It can also include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), and resolving, selecting, choosing, and establishing.

[0259]

[0289] The phrase "based on" does not mean "based on only" unless explicitly specified otherwise. In other words, the phrase "based on" describes both "based on only" and "based on at least." Furthermore, the phrase "based on" does not exclude intermediate steps, meaning, for example, A is based on C, B is based on C, and A is based on B. In addition, the term "and / or" means "and" or "or." For example, "A and / or B" can mean "A," "B," or "A and B." Furthermore, "A, B, and / or C" can mean "A only," "B only," "C only," "A and B," "A and C," "B and C," or "A, B, and C."

[0260]

[0290] The terms “connected,” “coupled,” and “communicatively coupled” and related terms are used in an operational sense and are not necessarily limited to direct physical connection or coupling. Therefore, for example, two devices may be coupled directly or through one or more intermediate media or devices. Another example is physical connection to each other. Devices can be joined in such a way that information can be passed between them without sharing a physical connection. Based on the disclosures provided herein, those skilled in the art will understand the various methods by which connection or joining exists in accordance with the definitions set forth herein.

[0261]

[0291] The phrases “in exemplary embodiments,” “in exemplary embodiments,” “in some embodiments,” “according to some embodiments,” “in shown embodiments,” “in other embodiments,” “embodiments,” “examples,” “examples,” “in some examples,” and “some examples” generally mean that the particular features, structures, or characteristics following the phrase are included in at least one embodiment of the Disclosure, and may be included in more than one embodiment of the Disclosure. Furthermore, such phrases do not necessarily refer to the same or different embodiments.

[0262]

[0292] Where the specification states that a component or feature "may," "can," "possibly," or "might" include or have the characteristics of that particular component or feature, that particular component or feature does not necessarily have to include or have the characteristics of that component or feature.

[0263]

[0293] The term "respond" includes responding completely or partially.

[0264]

[0294] The term "module" broadly refers to a component of software, hardware, or firmware (or any combination thereof). A module is typically a functional component that can produce useful data or other outputs using given inputs. Modules may or may not be self-contained. An application program (also called an "application") may contain one or more modules, or a module may contain one or more application programs.

[0265]

[0295] The term “network” generally refers to a group of interconnected devices that can exchange information. A network can range from a few personal computers on a local area network (LAN) to something as large as the Internet (a global network of computers). As used herein, “network” is intended to encompass any network on which information can be transmitted from one entity to another. In some cases, a network may consist of multiple networks, or even multiple heterogeneous networks interconnected via gateways that can facilitate communication between various networks, such as one or more border networks, voice networks, broadband networks, financial networks, service provider networks, Internet service provider (ISP) networks, and / or public switched telephone networks (PSTNs).

[0266]

[0296] Furthermore, for illustrative purposes, various embodiments of this disclosure have been described herein in the context of computer programs, physical components, and logical interactions within modern computer networks. Importantly, while these embodiments describe various embodiments of this disclosure in relation to modern computer networks and programs, the methods and apparatus described herein are equally applicable to other systems, devices, and networks, as those skilled in the art will understand. Accordingly, the illustrated uses of the embodiments of this disclosure are intended to be examples, not limitations. Other systems, devices, and networks to which the embodiments of this disclosure are applicable include, for example, other types of communication and computer devices and systems. More specifically, the embodiments are applicable to communication systems, services, and devices such as cell phone networks and compatible devices. Furthermore, the embodiments are suitable for all levels of computing, from personal computers to large network mainframes and servers. It is usable.

[0267]

[0297] In conclusion, this disclosure provides a novel multi-authorization system that uses M out of N keys to restore a customer wallet and associated method. While a detailed description of one or more embodiments of this disclosure has been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without departing from the spirit of this disclosure. In examples, the embodiments described above refer to specific features, but the scope of this disclosure also includes embodiments having different combinations of features, and embodiments that do not include all of the described features. Accordingly, the scope of this disclosure is intended to encompass all such alternatives, modifications, and variations that fall within the claims, along with all of its equivalents. Therefore, the above description should not be construed as limiting.

[0268] Examples

[0298] Example 1 includes a computing system comprising: at least one processor; at least one memory communicatively coupled to at least one processor; and at least one network interface communicatively coupled to at least one processor and configured to communicate with a customer device and a trusted third party, wherein the at least one network interface is configured to receive customer identity data and a request to restore the customer wallet from the customer device; the at least one processor is configured to verify the customer identity data received from the customer device; once the at least one processor has verified the customer identity data received from the customer device, the at least one network interface is configured to communicate a request to a trusted third-party key repository for a first key associated with the customer wallet; and the at least one processor is configured to restore the customer wallet using the first key associated with the customer wallet and a second key associated with the customer wallet.

[0269]

[0299] Example 2 includes the computing system of Example 1 and further includes the following. When at least one network interface receives a first key associated with the customer wallet from a reliable third-party key repository, at least one processor is configured to restore the customer wallet using the first key associated with the customer wallet and a second key associated with the customer wallet.

[0270]

[0300] Example 3 includes the computing system of Example 2, and at least one processor is configured to generate one or more new secret keys associated with a new customer wallet, generate a new transaction address associated with the new customer wallet based on the one or more new secret keys, and transfer digital assets from an old customer wallet to the new transaction address using the first key and the second key, and at least partially restore the customer wallet using the first key associated with the customer wallet and the second key associated with the customer wallet.

[0271]

[0301] Example 4 includes the computing system of Example 3, and the customer wallet includes a plurality of old transaction addresses each associated with three secret keys, and each old transaction address requires at least two of the three secret keys associated with each old transaction address to access the digital assets of the respective old transaction address.

[0272]

[0302] Example 5 includes the computing system of any one of Examples 3 to 4, and at least one network interface is configured to communicate a new transaction address associated with the new customer wallet to the customer device.

[0273]

[0303] Example 6 includes the computing system of Example 5, wherein at least one network interface is configured to communicate one or more new secret keys to a customer device.

[0274]

[0304] Example 7 includes the computing system from Example 6, and the new private key is a private transaction key.

[0275]

[0305] Example 8 includes a computing system from any of Examples 1 to 7, wherein at least one processor is configured to verify, at least partially, customer identity data received from a customer device by comparing the identity data with previously stored customer identity data.

[0276]

[0306] Example 9 includes one of the computing systems from Examples 1 to 8, and the identity data comprises biometric data.

[0277]

[0307] Example 10 includes a computing system from any of Examples 1 through 9, and the trusted third party is at least one of a credit union or a bank.

[0278]

[0308] Example 11 includes a computing system from any of Examples 1 through 10, and the customer wallet is used to store at least one of securities, currencies, commodities, bonds, funds, or a combination thereof.

[0279]

[0309] Example 12 includes a system comprising: a computing device configured to communicate with a trusted third party and the customer's customer device; and a key repository communicatively coupled to the computing device, wherein the computing device is configured to receive customer identity data and a request to restore the customer wallet from the customer device; the computing device is configured to verify the customer identity data received from the customer device; the computing device is configured to communicate a request to a trusted third-party key repository for a first key associated with the customer wallet; and the computing device restores the customer wallet using the first key associated with the customer wallet and a second key associated with the customer wallet.

[0280]

[0310] Example 13 includes the system of Example 12, and further comprises the following: When a computing device receives a first key associated with a customer wallet from a trusted third-party key repository, the computing device is configured to restore the customer wallet using the first key associated with the customer wallet and a second key associated with the customer wallet.

[0281]

[0311] Example 14 includes the system of Example 13, wherein the computing device is configured to generate one or more new private keys associated with a new customer wallet, generate a new transaction address associated with the new customer wallet based on the one or more new private keys, and restore the customer wallet at least partially using the first key and the second key associated with the customer wallet by transferring digital assets from the old customer wallet to the new transaction address using the first and second keys.

[0282]

[0312] Example 15 includes the system of Example 14, where the customer wallet has multiple old transaction addresses, each associated with three private keys, and each old transaction A transaction address requires at least two of the three private keys associated with each old transaction address in order to access the digital assets of each old transaction address.

[0283]

[0313] Example 16 includes one of the systems from Examples 14 to 15, wherein the computing device is further configured to communicate a new transaction address associated with a new customer wallet to the customer device.

[0284]

[0314] Example 17 includes the system of Example 16, wherein the computing device is further configured to communicate one or more new secret keys to the customer device.

[0285]

[0315] Example 18 includes the system from Example 17, and the new private key is a private transaction key.

[0286]

[0316] Example 19 includes any of the systems in Examples 12 through 18, wherein the computing device is configured to verify, at least partially, customer identity data received from the customer device by comparing the identity data with previously stored customer identity data.

[0287]

[0317] Example 20 includes one of the systems from Examples 12 to 19, and the identity data includes biometric data.

[0288]

[0318] Example 21 includes any of the systems from Examples 12 through 20, and the trusted third party is at least one of the following: a credit union or a bank.

[0289]

[0319] Example 22 includes any of the systems from Examples 12 to 21, and the customer wallet is used to store at least one of the following: securities, currencies, commodities, bonds, funds, or a combination thereof.

[0290]

[0320] Example 23 includes a computerized method comprising: a computing device receiving customer identity data and a request to restore a customer wallet from a customer device; the computing device verifying the customer identity data received from the customer device; once the customer identity data received from the customer device has been verified, communicating a request to a trusted third-party key repository for a first key associated with the customer wallet; and receiving the first key associated with the customer wallet from the trusted third-party key repository, the customer wallet being restored using the first key associated with the customer wallet and a second key associated with the customer wallet.

[0291]

[0321] Example 24 includes the computerized method of Example 23, and further comprises: restoring the customer wallet on a computing device using a first key associated with the customer wallet and a second key associated with the customer wallet.

[0292]

[0322] Example 25 includes the computerized method of Example 24, and restoring a customer wallet on a computing device using a first key associated with the customer wallet and a second key associated with the customer wallet comprises generating one or more new private keys associated with the new customer wallet, generating a new transaction address associated with the new customer wallet based on the one or more new private keys, and transferring digital assets from the old customer wallet to the new transaction address using the first and second keys.

[0293]

[0323] Example 26 includes a computerized version of Example 25, where the customer wallet has multiple old transaction addresses, each associated with three private keys, and each old transaction address requires at least two of the three private keys associated with that old transaction address to access the digital assets of that old transaction address.

[0294]

[0324] Example 27 includes a computerized method of any of Examples 25-26, and further comprises communicating a new transaction address associated with a new customer wallet to the customer device.

[0295]

[0325] Example 28 includes a computerized method of any of Examples 25 to 27, and further comprises communicating one or more new secret keys to a customer device.

[0296]

[0326] Example 29 includes the computerized method of Example 28, where the new private key is a private transaction key.

[0297]

[0327] Example 30 includes a computerized method of any of Examples 23 to 29, wherein verifying customer identity data received from a customer device on a computing device comprises comparing the identity data with previously stored customer identity data.

[0298]

[0328] Example 31 includes a computerized method from any of Examples 23 to 30, wherein the identity data comprises biometric data.

[0299]

[0329] Example 32 involves a computerized method from any of Examples 23 through 31, where the trusted third party is at least one of a credit union or a bank.

[0300]

[0330] Example 33 includes a computerized method of any of Examples 23 through 32, wherein the customer wallet is used to store at least one of securities, currencies, commodities, bonds, funds, or a combination thereof.

Claims

1. At least one processor, At least one memory connected to the aforementioned at least one processor in a communicative manner, The system comprises at least one network interface that is communicatively coupled to the at least one processor and configured to communicate with customer devices and trusted third parties, The at least one network interface is configured to receive customer identity data and a request to restore the customer wallet from the customer device. The at least one processor is configured to verify the customer's identity data received from the customer device, When the at least one processor verifies the customer's identity data received from the customer device, the at least one network interface is configured to communicate a request to the trusted third-party key repository for a first key associated with the customer wallet. A computing system in which at least one processor is configured to restore the customer wallet using the first key associated with the customer wallet and the second key associated with the customer wallet.

2. The computing system according to claim 1, wherein when the at least one network interface receives the first key associated with the customer wallet from the trusted third-party key repository, the at least one processor is configured to restore the customer wallet using the first key associated with the customer wallet and the second key associated with the customer wallet.

3. The aforementioned at least one processor is Generate one or more new private keys associated with the new customer wallet, Based on the one or more new private keys, a new transaction address associated with the new customer wallet is generated. By using the first key and the second key, the digital assets are transferred from the old customer wallet to the new transaction address. The computing system according to claim 2, configured at least partially to restore the customer wallet using the first key associated with the customer wallet and the second key associated with the customer wallet.

4. Each customer wallet has multiple old transaction addresses, each associated with three private keys. The computing system according to claim 3, wherein each old transaction address requires at least two of the three private keys associated with each old transaction address in order to access the digital assets of each old transaction address.

5. The at least one network interface is The computing system according to claim 3, configured to communicate the new transaction address associated with the new customer wallet to the customer device.

6. The at least one network interface is One or more of the new secret keys are configured to communicate to the customer device. The computing system according to claim 5.

7. The computing system according to claim 6, wherein the new private key is a private transaction key.

8. The aforementioned at least one processor is By comparing the aforementioned identity data with the previously stored customer identity data, The computing system according to claim 1, configured at least partially to verify the customer's identity data received from the customer device.

9. The computing system according to claim 1, wherein the identity data comprises biometric data.

10. The computing system according to claim 1, wherein the trusted third party is at least one of a credit union or a bank.

11. The computing system according to claim 1, wherein the customer wallet is used to store at least one of securities, currencies, commodities, bonds, funds, or combinations thereof.

12. Computing devices configured to communicate with trusted third parties and customer devices, The system comprises a key repository that is communicatively coupled to the computing device, The computing device is configured to receive customer identity data and a request to restore the customer wallet from the customer device. The computing device is configured to verify the customer's identity data received from the customer device, The computing device is configured to communicate a request for the first key associated with the customer wallet to the trusted third-party key repository. The computing device is a system that restores the customer wallet using the first key associated with the customer wallet and the second key associated with the customer wallet.

13. The system according to claim 12, wherein when the computing device receives the first key associated with the customer wallet from the trusted third-party key repository, the computing device is configured to restore the customer wallet using the first key associated with the customer wallet and the second key associated with the customer wallet.

14. The computing device is Generate one or more new private keys associated with the new customer wallet, Based on the one or more new private keys, a new transaction address associated with the new customer wallet is generated. By using the first key and the second key, the digital assets are transferred from the old customer wallet to the new transaction address. The system according to claim 13, configured at least partially to restore the customer wallet using the first key associated with the customer wallet and the second key associated with the customer wallet.

15. Each customer wallet has multiple old transaction addresses, each associated with three private keys. The system according to claim 14, wherein each old transaction address requires at least two of the three private keys associated with each old transaction address in order to access the digital assets of each old transaction address.

16. The computing device further, The system according to claim 14, configured to communicate the new transaction address associated with the new customer wallet to the customer device.

17. The computing device further, The system according to claim 16, configured to communicate the one or more new secret keys to the customer device.

18. The system according to claim 17, wherein the new private key is a private transaction key.

19. The computing device is By comparing the aforementioned identity data with the previously stored customer identity data, The system according to claim 12, configured at least partially to verify the customer's identity data received from the customer device.

20. The system according to claim 12, wherein the identity data comprises biometric data.

21. The system according to claim 12, wherein the trusted third party is at least one of a credit union or a bank.

22. The system according to claim 12, wherein the customer wallet is used to store at least one of securities, currencies, commodities, bonds, funds, or combinations thereof.

23. A computing device receives customer identity data and a request to restore the customer wallet from a customer device. The computing device verifies the customer's identity data received from the customer device, Once the customer's identity data received from the customer device is verified, the customer communicates a request to a trusted third-party key repository for the first key associated with the customer wallet. The process includes the step of receiving the first key associated with the customer wallet from the trusted third-party key repository, A computerized method by which the customer wallet can be restored using the first key associated with the customer wallet and the second key associated with the customer wallet.

24. The computerized method according to claim 23, further comprising the step of restoring the customer wallet on the computing device using the first key associated with the customer wallet and the second key associated with the customer wallet.

25. The first key associated with the customer wallet and the customer wallet The step of restoring the customer wallet on the computing device using the second key obtained is: The steps include generating one or more new private keys associated with a new customer wallet, The steps include generating a new transaction address associated with the new customer wallet based on the one or more new private keys, The computerized method according to claim 24, comprising the step of transferring digital assets from an old customer wallet to the new transaction address using the first key and the second key.

26. Each customer wallet has multiple old transaction addresses, each associated with three private keys. The computerized method according to claim 25, wherein each old transaction address requires at least two of the three private keys associated with each old transaction address in order to access the digital assets of each of the old transaction addresses.

27. The computerized method according to claim 25, further comprising the step of communicating the new transaction address associated with the new customer wallet to the customer device.

28. The computerized method according to claim 25, further comprising the step of communicating one or more of the new secret keys to the customer device.

29. The computerized method according to claim 28, wherein the new private key is a private transaction key.

30. In the computing device, the step of verifying the customer's identity data received from the customer device is: The computerized method according to claim 23, further comprising the step of comparing the identity data with previously stored customer identity data.

31. The computerized method according to claim 23, wherein the identity data comprises biometric data.

32. The computerized method according to claim 23, wherein the trusted third party is at least one of a credit union or a bank.

33. The computerized method according to claim 23, wherein the customer wallet is used to store at least one of securities, currencies, commodities, bonds, funds, or combinations thereof.

Images