Multi-approval system using m of n keys to restore customer wallet

Abstract

To provide a method and a system for performing access as required while keeping keys safely for a multi-approval cryptocurrency account and a transaction.SOLUTION: A network interface of a currency conversion system receives identity data of a customer and a request to restore a customer wallet from a customer device. A processor of the currency conversion system verifies the identity data of the customer received from the customer device. When the processor of the currency conversion system verifies the identity data of the customer received from the customer device, the network interface of the currency conversion system communicates a request to calculate a first key associated with the customer wallet to a key repository of a trusted third party. The processor of the currency conversion system uses the first key associated with the customer wallet and a second key associated with the customer wallet to restore the customer wallet.SELECTED DRAWING: Figure 9A

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application was filed on January 17, 2018, and is related to "MULTI-SIGNATURE (MULTI-SIG) WITH THREE KEYS REQUIRING TWO OF THREE KEYS TO ACCESS CRYPTOCURRENCY No. 62 / 618,077 (Attorney Docket No. 270.018USPR), filed on April 27, 2018, entitled “MULTI-APPROVAL CRYPTOCURRENCY SYSTEM REQUIRING M OF N KEYS WALLET AND STORING KEYS WITH USER, TRUSTED 3RD PARTY, AND EXCHANGE”; U.S. Provisional Patent Application No. 62 / 663,921 (Attorney Docket No. 270.018USP2), filed on April 27, 2018, entitled “MULTI-APPROVAL CRYPTOCURRENCY SYSTEM REQUIRING M OF N KEYS TO ACCESS AND RESTORE CRYPTOCURRENCY WALLET” and ... This application claims the benefit of U.S. Provisional Patent Application No. 62 / 663,922 (Attorney Docket No. 270.019 USPR), entitled “MULTI-APPROVAL CRYPTOCURRENCY WALLET” and U.S. Provisional Patent Application No. 62 / 780,779 (Attorney Docket No. 270.027 USPR), filed December 17, 2018, entitled “MULTI-APPROVAL CRYPTOCURRENCY SYSTEM,” all of which are incorporated herein by reference.

[0002]

[0002] This application is related to the following co-pending US patent applications, which are incorporated herein by reference:

[0003]

[0003] U.S. patent application Ser. No. __________ (Attorney Docket No. 270.019US01), entitled "MULTI-APPROVAL SYSTEM USING M OF N KEYS TO GENERATE A TRANSACTION ADDRESS," filed on the same day as this application, and incorporated herein by reference.

[0004]

[0004] U.S. patent application Ser. No. __________ (Attorney Docket No. 270.027US01), entitled "MULTI-APPROVAL SYSTEM USING M OF N KEYS TO PERFORM AN ACTION AT A CUSTOMER DEVICE," filed on the same day as this application, and incorporated herein by reference.

[0005]

[0005] "MULTI-APPROVAL SYSTEM USING M OF N KEYS TO GENERATE A SWEEPING TRANSACTION AT A CUSTOMER DEVICE" No. 6,399,623, filed on even date herewith, and incorporated herein by reference. [Background technology]

[0006]

[0006] Encryption can be used to store and transmit data securely. A key can be used to encrypt data and to decrypt encrypted data. Summary of the Invention

[0007]

[0007] A computing system is disclosed that 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 a customer wallet. The at least one processor is configured to verify the customer identity data received from the customer device. Upon the at least one processor verifying the customer identity data received from the customer device, the at least one network interface is configured to communicate a request for a first key associated with the customer wallet to a key repository of the trusted third party. 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] With the understanding that the drawings illustrate only exemplary embodiments and therefore should not be considered limiting of the scope, exemplary embodiments will be described with additional specificity and detail through the use of the accompanying drawings. [Brief description of the drawings]

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

[0010]

[0040] According to common practice, the various features illustrated are not drawn to scale but are drawn to emphasize particular 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 which show, by way of illustration, specific exemplary embodiments. It is to be understood, however, that other embodiments may be utilized and that logical, mechanical, and electrical changes may be made. Furthermore, the methods presented in the drawings and the specification should not be construed as limiting the order in which individual steps may be performed. Thus, the following detailed description is not to be construed in a limiting sense. You shouldn't.

[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, encryption keys, signing keys, other cryptographic keys, as well as passwords and secrets. One issue with keys is keeping them safe and making them accessible when needed. In some cases, it is undesirable to restrict access to a wallet to a singular person / entity, as this may leave the wallet vulnerable to malicious attacks. Instead, it may be desirable to require validation by multiple people / entities to use the wallet.

[0013]

[0043] Multiple private keys can be used in a multiple signature (multisig) scenario where M / N (e.g., 2 / 3) keys are required to use or restore the wallet. Distributing the keys among different devices reduces the chances of unauthorized users gaining access to the wallet. In an example, three private keys are generated and distributed among the various devices in a multisig system: (1) a first key held by the customer (end user), (2) a second key held by a 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] As an alternative to multisig, a key can be split into multiple key components (i.e., parts) and a subset of the key components can be used to reconstruct the key, i.e., key split. In an example, a certain number of key components may be required to reconstruct a particular key. For example, a particular key may be split into N key components and M (e.g., 2 / 3) of the N key components are required to reconstruct the particular key. In an example, the N key components may be distributed to various users, e.g., (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 an example, the key is split into a set of key components by at least one of polynomial interpolation or Shamir secret sharing.

[0015]

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

[0016]

[0046] During normal operation, private keys from both the customer (end user) and the currency conversion system / exchange may be required to transact from the customer wallet, for example to transfer cryptocurrency from a transaction address. If a user loses their private key (e.g., if they lose, destroy, or upgrade the device that contained it), the currency conversion system / exchange and a trusted third party (e.g., a credit union or bank) may need to provide the private key to the user. The private key of the customer (e.g., a customer or bank) 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, or (3) a trusted third party (e.g., a credit union or bank).

[0017]

[0047] 1 is a block diagram illustrating an example system 100 for multi-approval 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. Additionally, system 100 may include more than one of each device.

[0018]

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

[0019]

[0049] In examples, 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 source. Additionally, 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] The system 100 can use a multi-approval methodology, for example, a multi-party multi-signature (multisig) methodology, a multi-party key splitting methodology, or a combination of the two. A multi-party multi-signature (multisig) methodology can distribute a different private key (e.g., a unique string 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, e.g., as signed 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 some combination. With the multisig methodology, the private key does not need to be split.

[0021]

[0051] Alternatively, the 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 suitable number) key components. In an example, the key components may be generated using polynomial interpolation or Shamir secret sharing. In a multi-party key splitting methodology, a different key component may be located at 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 must be signed using M out of N key components (e.g., ⅔ of the key components), e.g., as signed by the customer device 102 and the currency conversion system 104. The private key may be reconstructed at the customer device 102, the currency conversion system 104, or the trusted third party 106.

[0022]

[0052] Configurations disclosed herein using multisig methodologies (i.e., signing a transaction or purchase request with M / N private keys) may instead use key splitting (i.e., reconstructing a private key with M / N private key components and then signing the transaction or purchase request using the private keys).

[0023]

[0053] Alternatively, the system 100 may use a combination of multi-party multisig and key splitting methodologies, where a first private key is split into two key components, with a different key component located at each of the customer device 102 and the currency conversion system 104. The second private key (which is not split) may be located at the trusted third party 106. Using this combination, any cryptocurrency purchase or transaction requested by a 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 "signing" or variations thereof refers to using a key (or key components) to add or modify data associated with a desired transaction; for example, signing a transaction may include using an M / N (e.g., 2 / 3) private key to encrypt or transform a transaction address. Additionally, a public key may be derived from a corresponding private key (or parent public key), and the public key may be used to derive a transaction address, monitor transactions of the transaction address, and / or display an account balance (e.g., on a blockchain). However, a public key cannot be used to transact from a transaction address, i.e., a public key cannot be used to sign a transaction. Rather, a device may execute a transaction from a transaction address using one or more private keys (or private key components).

[0025]

[0055] As used herein, unless otherwise specified, the term “customer” (or “user”) refers to a person (or automated instructions, e.g., scripts) that accesses a customer device 102 to initiate any of the functions described herein, such as, for example, creating a multisig account, purchasing multisig cryptocurrency, conducting multisig transactions using cryptocurrency, restoring a multisig account, etc.

[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 cryptocurrency. Although the present systems and methods are described herein using cryptocurrency, they are also compatible with any type of digital asset. In an example, a wallet is defined by one or more private keys, one or more public keys derived from the one or more private keys, and / or one or more transaction addresses derived from the one or more private keys and / or the one or more public keys. In an example, a wallet can be defined with one or more private account keys (and, optionally, corresponding public account keys), each of which can have one or more child and / or grandchild transaction keys.

[0027]

[0057] As used herein, the term "distributed ledger" refers to an electronic ledger that is distributed across multiple interconnected nodes, with two or more of the nodes storing a copy of the ledger. In an example, the distributed ledger 118 may implement one or more blockchains to verify data stored within the distributed ledger 118. A blockchain is a verifiable, permanent ledger that is built one block at a time, with a proof-of-work seal (e.g., a hash) attached to each block that verifies that block. In a blockchain, the hash of the previous block is included in the current block, so that recursion allows for the proof of work of the previous block to be verified. The current hash validates all previous blocks back to the original genesis block. Inserting a hash into the blockchain permanently records that hash and acts as a notary to verify the proof of existence of the timestamped hash data at the time that block is added to the chain. Future blocks add a layer of protection from manipulation of data stored in the chain or reorganization of the chain, thus adding certainty that changes cannot be made to earlier blocks in the chain. A blockchain is an implementation of a distributed ledger 118 and can be public (i.e., visible to anyone) or private. 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 an example, the customer device 102 may be a mobile device using, for example, an Android® or iOS® operating system. A customer may download an application corresponding to the currency conversion system 104 to the customer device 102. The application may present a user interface on the customer device 102, and the customer may provide input using the user interface. Based at least in part on the user input, the application on the customer device 102 may send and receive instructions and / or other data to and from the currency conversion system 104. In an example, the application on the customer device 102 may communicate directly only with the currency conversion system 104, which communicates with other devices of the system 100, i.e., the currency conversion system 104 may be a gateway to other devices of the system 100. Alternatively, the application on the customer device 102 may communicate directly with the trusted third party 106, the currency conversion system 104, and / or other devices in the system 100.

[0029]

[0059] The currency conversion system 104 may be a bank or a non-bank financial institution that converts currency to other forms of currency, e.g., a money service business (MSB). In an 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., a database and / or a secure memory) associated with one or more customer wallets. The key repository 114 may be physically located on the same or a different device that performs other functions of the currency conversion system 104. The currency conversion system 104 may or may not have a money transmission license as required under applicable rules and regulations.

[0030]

[0060] In an example, the currency conversion system 104 may assist end users (i.e., customers) in purchasing cryptocurrencies such as Bitcoin. Specifically, the currency conversion system 104 may enable customers to convert the currency into other forms of currency, e.g., fiat currency into cryptocurrencies (e.g., Bitcoin), cryptocurrencies (e.g., Bitcoin) into fiat currency, one type of cryptocurrency (e.g., Bitcoin) into another form of currency (e.g., Ethereum), etc. In an example, the currency conversion system 104 may also enable customers to transact using the cryptocurrencies, i.e., buy and / or sell goods and / or services in exchange for the cryptocurrencies. In addition to cryptocurrencies, the currency conversion system 104 may also enable customers to convert other types of assets, e.g., at least one security, at least one bond, at least one commodity, at least one real estate, at least one item of personal wealth, at least one fund, at least one currency fund, at least one exchange-traded fund, at least one mutual fund, at least one index fund, at least one bond fund, at least one commodity ... The purchase and / or transaction may be enabled using a combination of a real estate investment trust, a real estate investment trust fund, or at least one real estate fund.

[0031]

[0061] To enable purchases of cryptocurrencies and transactions using cryptocurrencies, the currency conversion system 104 can be in communication with an asset exchange 108. The asset exchange 108 can be a marketplace (and / or an entity operating a marketplace) where securities, commodities, derivatives, and / or other financial instruments are traded, e.g., Kraken, SFOX, Coinbase®, etc. In an example, the asset exchange 108 can serve as a marketplace for cryptocurrencies, digital currencies, fiat currencies, and / or commodity currencies. In an example, the asset exchange 108 described herein can record successfully executed transactions on a distributed ledger 118, e.g., 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 private asset, at least one fund, at least one currency fund, at least one exchange-traded 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 an example, the trusted third party 106 may be implemented using one or more trusted computing devices that are trusted to validate transactions between two parties. In an 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 at the trusted third party 106 may indicate that a pending transaction should be signed (e.g., authenticated) using a private key stored at the trusted third party 106. The trusted third party 106 may also communicate with the 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., database and / or secure memory) associated with one or more customer wallets. The key repository 116 may be physically located on the same or a different device that performs other functions of the trusted third party 106. In an example, the key (or key components) stored in the key repository 116 for the trusted third party 106 may be used only in an emergency, such as, for example, if the customer device 102 (and any keys stored thereon) is lost, destroyed, upgraded, or hard reset / reformatted. In an example, the trusted third party 106 may have a money transmitting license as required under applicable rules and regulations.

[0033]

[0063] The identity service provider 110 may be one or more computing devices that provide anti-money laundering (AML) and / or know-your-customer (KYC) services. AML services may include one or more steps to ensure that a potential (or current) customer is not violating relevant laws and regulations designed to combat money laundering. That is, AML services require a potential (or current) customer to ensure that they have not taken steps to conceal the source of funds received from illegal or unethical activities. KYC services include collecting and verifying information regarding the identity and / or financial transactions of a potential (or current) customer. , may include one or more steps to monitor. In an example, KYC services may include collecting basic identity data (e.g., name, contact information, etc.), verifying that the customer is who they say they are, and / or verifying that the customer is not on a law enforcement watch list. KYC services may also include (e.g., based on the customer's basic identity data), performing soft credit checks, analyzing the customer's transaction behavior, and / or monitoring the customer's account for fraudulent activity based on the customer's transaction behavior. AML and KYC may be required under various federal, state, and / or local laws.

[0034]

[0064] Each of the devices in the system 100 may be communicatively coupled to one or more other devices using at least one network 112 (e.g., networks 112A-B). In an example, the at least one network 112 includes at least one wired network and / or at least one wireless network. In an example, any combination of wired and wireless networks may be used to couple the customer devices 102, the currency conversion system 104, and the trusted third party 106 to one another. In an example, the 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 an example, any combination of a local area network, a wide area network, or the Internet may be used as the at least one network 112 to couple the customer devices 102, the currency conversion system 104, and the trusted third party 106 to one another.

[0035]

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

[0036]

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

[0037]

[0067] FIG. 2A illustrates an exemplary node on a customer device 102 for implementing a customer wallet. Node tree 200A is a block diagram illustrating a hierarchical deterministic (HD) wallet for a customer according to portions of Bitcoin Improvement Proposal 32 (BIP32) and / or portions 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] Node tree 200A may exist on customer device 102 and may include hierarchical levels. Specifically, node tree 200A may include private account key 204 and public account key 205 at a first level (L1). Private account key 204 may be a unique string of numbers, letters, and / or other characters specific to a customer. Private account key 204 may further be specific to a type of cryptocurrency, e.g., customer device 102 may include a different private account key 204 for each type of cryptocurrency stored in a customer wallet. In an example, customer device 102 may store a separate private account key 204 for each of Bitcoin, Ethereum, Litecoin, etc. A customer wallet may be defined by private account key 204 and / or other private account keys (not shown).

[0039]

[0069] Optionally, private account key 204 may be generated at customer device 102 based on seed 201, for example, a seed derived from a mnemonic code or sentence according to Bitcoin Improvement Proposal 39 (BIP39) (available at https: / / github.com / bitcoin / bips / blob / master / bip-0039.mediawiki, incorporated herein by reference). Alternatively, private account key 204 may be generated at 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, i.e., the private account key 204 may determine the public account key 205. In an example, the customer device 102 may use a hash function, e.g., a SHA256 function, to derive the public account key 205 from the private account key 204. However, the public account key 205 typically (and preferably) does not determine the private account key 204, e.g., 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 may be “extended” keys, meaning that a chaincode is appended to the key string. In an example, the private account key 204 and the public account key 205 may each be 256 bits long with an additional 256-bit chaincode, i.e., the extended private account key 204 and the extended public account key 205 may each be 512 bits long. An extended key can be used to derive child keys, whereas a non-extended (or “hardened”) key cannot be used to derive child keys. Because they are extended keys, it may be desirable to not transmit the private account key 204 and the public account key 205 from the customer device 102 to the currency conversion system 104 or the trusted third party 106.

[0042]

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

[0043]

[0073] Each secret transaction key 206 can range, for example, from 0 to (2 32 Each node tree 200A may have an associated index in the range of 100-100 (i.e., 100-100). The index may be used to navigate the node tree 200A, i.e., the index may uniquely identify the location of a corresponding particular private transaction key 206. Thus, the index may be transmitted between devices as an efficient way of identifying the private transaction key 206. In an example, a device receiving an index may generate the corresponding private transaction key 206 from its own node tree.

[0044]

[0074] Similarly, public account key 205 may have one or more optional public transaction keys 207A-B at a second level (L2) of node tree 200A. Each public transaction key 207 may be derived from public account key 205 or from associated private transaction key 206 using a child key derivation (CKD) function (e.g., 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. Public transaction key 207 may be a non-enhanced (i.e., hardened) key and may not be used to derive further child keys. Thus, private transaction key 206 and / or public transaction key 207 may be transmitted from customer device 102 to currency conversion system 104 and / or trusted third party 106 for multi-approval transactions requiring M keys out of N.

[0045]

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

[0046]

[0076] In an example, node tree 200A may include many (e.g., hundreds, thousands, millions, or billions) of private transaction keys 206, e.g., 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 all of the cryptocurrency of an existing transaction address. Additionally, node tree 200A may include many (e.g., hundreds, thousands, millions, or billions) of public transaction keys 207, e.g., one corresponding to each private transaction key 206 in node tree 200A.

[0047]

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

[0048]

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

[0049]

[0079] The node tree 200B may be stored in the currency conversion system 104 (e.g., 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 private key 212 at a first level (L0). Specifically, the currency conversion system 104 may store a single master private key 212 that is used to derive one or more private account keys 214A-B. In other words, the master private key 212 may be a parent private key of all private account keys 214 stored in the currency conversion system 104. Optionally, the master private key 212 may be generated in the currency conversion system 104 based on a seed 211, e.g., a seed derived from a mnemonic code or sentence according to BIP39. Alternatively, the master private 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 a parent public key for all public account keys 215A-B on the currency conversion system 104. The master private key 212 and the master public key 213 may be extended keys. Thus, it may be preferable to avoid transmitting the master private key 212 and the master public key 213 from the currency conversion system 104.

[0051]

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

[0052]

[0082] In an example, node tree 200B may include a private account key 214 and a public account key 215 for each customer per cryptocurrency type, i.e., if 10 customers each hold three different types of cryptocurrency with currency conversion system 104, node tree 200B may include 30 (i.e., 10 x 3) private account keys 214 and 30 public account keys 215. Because these are extended keys, it may be desirable to not send the private account keys 214 and public account keys 215 from the currency conversion system 104 to the customer device 102 or 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) the private account keys and public account keys stored in 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 private transaction keys 216A-D, for example at a third level (L2) of the node tree 200B. Each private transaction key 216 may be derived from one of the private 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). Public account keys 217 may be derived from one of the public account keys 215 using a child key derivation (CKD) function (e.g., as described in BIP32) or from the associated private transaction key 216. Alternatively, each public transaction key 217 may be derived directly from one of the private account keys 216 or from one of the private account keys 214.

[0056]

[0086] The private transaction key 216 and the public transaction key 217 may be unexpanded (i.e., hardened) keys and may not be used to derive further child keys. Thus, 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 the trusted third party 106 for a multi-approval transaction requiring M of N (e.g., 2 / 3) keys.

[0057]

[0087] Each secret transaction key 216 can range, for example, from 0 to (2 32 Each private transaction key 216 may have an associated index in the range of 100-1000 (-1). The index may be used to navigate the node tree 200B, i.e., the index may uniquely identify the location of a corresponding particular private transaction key 216. Thus, the index may be transmitted between devices as an efficient way of identifying the private transaction key 216. In an example, a device receiving an index may generate the corresponding private transaction key 216 from its own node tree.

[0058]

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

[0059]

[0089] In an example, node tree 200B may include many (e.g., hundreds, thousands, millions, or billions) of private transaction keys 216, e.g., 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 all of the cryptocurrency of an existing transaction address. Additionally, node tree 200B may include many (e.g., hundreds, thousands, millions, or billions) of public transaction keys 217, e.g., one corresponding to each private transaction key 216 of node tree 200B.

[0060]

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

[0061]

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

[0062]

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

[0063]

[0093] The master private key 222 may be used to derive a master public key 223, which may be a parent public key for all public account keys 225A-B on the trusted third party 106. The master private key 222 and the 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 an example, the master public key 223 may be copied to a secure portable memory (e.g., a portable hard drive) that is physically moved 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).

[0064]

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

[0065]

[0095] The private account keys 224A-B and public account keys 225A-B of the second level (L1) of node tree 200C may correspond (but are not identical) to the private account key 204 and public account key 205 in node tree 200A on customer device 102, and to the private 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 (but are not identical) to each other. In an example, to create a multi-confirmation transaction address, In an example, all three public account keys 205, 215A, 225A may be required to transact from a multi-confirmation transaction address. Similarly, the private account key 204 of the customer device 102, the first private account key 214A of the currency conversion system 104, and the first private account key 224A of the trusted third party 106 may correspond to each other (but are not identical). In an example, at least two of the private account keys 204, 214A, 224A may be required to transact from a multi-confirmation 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 the trusted third party 106 may have one or more optional private transaction keys 226A-D, for example at the third level (L2) of the 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] Node tree 200C may have one or more optional public transaction keys 227A-D at a 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 (e.g., as described in BIP32) or an associated private transaction key 226. 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 unenhanced (i.e., hardened) keys and may not be used to derive further child keys. Thus, the private transaction key 226 and / or the public transaction key 227 may be transmitted from the trusted third party 106 to the customer device 102 and / or the currency conversion system 104 for a multi-approval transaction requiring M of N keys.

[0069]

[0099] Each secret transaction key 226 can range, for example, from 0 to (2 32 The index may have an associated index in the range of 100-1000 (-1). The index may be used to navigate the node tree 200C, i.e., the index may uniquely identify the location of a corresponding particular private transaction key 226. Thus, the index may be transmitted between devices as an efficient way of identifying the private transaction key 226. In an example, the device receiving the index may generate the corresponding private transaction key 226 from its own node tree. Furthermore, a particular private transaction key 226 in the node tree 200C may correspond to (and have the same index as) a particular private transaction key 206 in the node tree 200A on the customer device 102 and a particular private transaction key 226 in the node tree 200B on the currency conversion system 104, e.g., private transaction key 206A, private transaction key 216A, and private transaction key 226A may correspond to each other and have the same index.

[0070]

[0100] Each public transaction key 227 can range, for example, from 0 to (2 32Each of the devices may have an associated index in the range of 100-1000 (i.e., 100-10000). The index may be used to navigate the node tree 200C, i.e., the index may uniquely identify the location of a corresponding particular public transaction key 227. Thus, the index may be transmitted between devices as an efficient way of identifying the public transaction key 227. In an example, a device receiving an index may generate the corresponding public transaction key 227 from its own node tree. Additionally, the index may be used to navigate the node tree 200C, i.e., the index may uniquely identify the location of a particular public transaction key 227. A transaction key 227 may correspond to (and have the same index as) a particular public transaction key 207 in node tree 200A on customer device 102 and a particular public transaction key 227 in node tree 200B on currency conversion system 104; for example, public transaction key 207A, public transaction key 217A, and public transaction key 227A may correspond to each other and have the same index.

[0071]

[0101] In an example, node tree 200C may include many (e.g., hundreds, thousands, millions, or billions) of private transaction keys 226, e.g., 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 all of the cryptocurrency in an existing transaction address. Additionally, node tree 200B may include many (e.g., hundreds, thousands, millions, or billions) of public transaction keys 227, e.g., one corresponding to each private transaction key 226 in node tree 200B.

[0072]

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

[0073]

[0103] 3 is a flow diagram illustrating an example method 300 for onboarding a customer in a multisig system. The method 300 may be performed by the customer device 102, the currency conversion system 104, the trusted third party 106, and the identity service provider 110 in the system 100 shown in FIG.

[0074]

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

[0075]

[0105] The customer may also input 304 identity and payment data into the application. 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, an image of the customer's government issued photo identification, a photo of the customer holding the government issued photo identification, employment information, and / or income. Identity data may also include biometric data, such as fingerprint data (e.g., a scan of the customer's fingerprint), retina 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 transmit only processed data derived from the raw biometric data, e.g., image features, voice features, etc.

[0076]

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

[0077]

[0107] The currency conversion system 104 may transmit 308 the identity data to the identity service provider 110. The identity service provider 110 may use the transmitted customer's identity data to perform 310 anti-money laundering (AML) and / or know-your-customer (KYC) procedures. AML may seek to verify that the customer is not laundering money, i.e., the customer has not taken steps to obscure the source of funds received from illegal or unethical activities. KYC may verify that the customer is who they claim to be and that the customer is not on a law enforcement watch list. KYC may also assess creditworthiness (e.g., with a soft credit check), analyze the customer's transaction behavior, and monitor the customer's account for fraudulent behavior based on the customer's transaction behavior. Once the AML and / or KYC procedures are completed, the identity service provider 110 may transmit 312 a notification to the currency conversion system 104 and the trusted third party 106. The notification may indicate the success or failure of the customer's AML and / or KYC procedures. In an example, the identity service provider 110 may send a report showing all AML and KYC checks it has 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 314 an account for the customer based on the notification. Creating the account may include generating a private account key 214 at 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 at the new index using, for example, a child key derivation (CKD) function according to BIP32.

[0079]

[0109] If the 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 316 an account for the customer based on the notification. Creating the account may include generating a private account key 224 at the trusted third party 106 for the customer. The trusted third party 106 may derive the private account key 224 for the customer from the master private key 222 at the new index using, for example, a child key derivation (CKD) function according to BIP32.

[0080]

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

[0081]

[0111] 4 is a flow diagram illustrating an example method 400 for purchasing cryptocurrency in a multisig system. The method 400 may be performed by the customer device 102, the currency conversion system 104, the trusted third party 106, and the asset exchange 108 in the system 100 shown in FIG.

[0082]

[0112] A customer may create 402 a cryptocurrency purchase order on an application on the customer device 102. The cryptocurrency purchase order may indicate a type of cryptocurrency (e.g., Bitcoin, Ethereum, etc.) and a desired quantity (in terms of cryptocurrency or fiat currency such as US Dollars). The cryptocurrency purchase order may also indicate optional attributes such as a limit price, a stop price, conditional trigger requirements, a term for the order, whether the order will be partially filled, etc. The customer may be required to provide a biometric input and / or a password to the customer device 102 during creation of the cryptocurrency purchase order.

[0083]

[0113] Optionally, the customer device 102 may sign the cryptocurrency purchase order using a private key stored on the customer device 102; e.g., the cryptocurrency purchase order may optionally be encrypted using a private key (or a public key derived from the private key) stored on the customer device 102. The cryptocurrency purchase order may also include a public address (of the customer wallet) derived from the public key or private key stored on the customer device 102.

[0084]

[0114] The customer device 102 may transmit 404 the cryptocurrency purchase order and customer payment data to the currency conversion system 104. The customer payment data may include payment data not previously stored in the currency conversion system 104 or instructions to use payment data previously stored in the currency conversion system 104. Optionally, the customer device 102 may transmit customer identity data, such as, for example, biometric data.

[0085]

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

[0086]

[0116] At or near the same time that the storage order is submitted, the currency conversion system 104 may also notify 412 the trusted third party 106 of the new transaction address in the cryptocurrency purchase order, the storage order, and / or the customer wallet. The currency conversion system 104 may generate a new transaction address for the customer wallet. This may include using the N public transaction keys (e.g., 207A, 217A, 227A) as inputs to a multi-approval hash function (along with the multi-approval condition input) to generate the transaction address for the customer wallet.

[0087]

[0117] The trusted third party 106 may act as a trusted party that authorizes certain types of transactions on the asset exchange 108. This may make the system 100 vulnerable to malicious attacks since the keys for authorizing transactions are decentralized. Additionally, the trusted third party 106 may be able to provide a mechanism for the transfer of funds. The trusted third party 106 may possess a gold license, but the currency conversion system 104 may not. The trusted third party 106 may instruct 416 the asset exchange 108 to transfer the cryptocurrency associated with the custody order from the custody wallet to a new transaction address in the customer wallet. Upon receiving instructions from the trusted third party 106, the asset exchange may record 416 in a distributed ledger 118 (e.g., a blockchain) the change of ownership of the cryptocurrency from the custody wallet to the new transaction address in the customer wallet.

[0088]

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

[0089]

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

[0090]

[0120] The currency conversion system 104 may receive the public transaction key 207A from the customer device 102. Although the public transaction key 207A may be used to derive a transaction address, monitor transactions of a transaction address, and / or view an account balance (e.g., on a blockchain), the public transaction key 207A may not be used to transact from an account. Furthermore, because the public transaction key 207A is hardened (i.e., not extended), it may not be used to derive child keys. Thus, there is a relatively low risk that the customer device 102 will share the public transaction key 207A with the currency conversion system 104.

[0091]

[0121] The currency conversion system 104 may also derive the public transaction key 217 from the node tree 200B stored in the currency conversion system 104. In an example, the currency conversion system 104 may derive the public transaction key 217 from a public account key 215, which is derived from a master public key 213, which is optionally derived from a master private key 212. Alternatively, the currency conversion system 104 may derive the public transaction key 217 from a private account key 214, which is derived from a master private key 212. Alternatively, the currency conversion system 104 may derive the public transaction key 217 from a public account key 215, which is derived from a private account key 214, which is derived from a master private key 212. In either case, the public transaction key 217 may 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. Again, because the master public key 223 is "public," it cannot be used for transactions or to derive private keys that can be used for transactions. The public key 223 may be used to derive public account keys 225 for many different customers and therefore may be securely transferred from the trusted third party 106 to the currency conversion system. In particular, the master public key 223 from the trusted third party 106 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 an example, the master public key 223 may be copied to a secure portable memory (e.g., a portable hard drive) that is physically moved 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 stored in the currency conversion system 104, the public account keys 225 may be derived from the master public key 223. The currency conversion system 104 may then derive the public transaction keys 227A from the public account keys 225.

[0094]

[0124] The currency conversion system 104 can then input the three public transaction keys 207A, 217A, 227A into a multi-confirmation hash module 528 to generate a multi-confirmation transaction address 530 along with a multi-confirmation condition 529. The multi-confirmation hash module 528 can use a hash algorithm to generate the multi-confirmation 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-confirmation transaction address 530 differs from a normal transaction address because M private keys (specified in the multi-confirmation condition 529) associated with the N input public keys are required to transact from the multi-confirmation transaction address 530. In the example, the multi-confirmation condition 529 specifies that two private keys (e.g., two of the private transaction keys 206A, 216A, 226A) associated with the three public transaction keys 207A, 217A, 227A are required to transact from the multi-confirmation transaction address 530.

[0095]

[0125] The currency conversion system 104 can send the multi-confirmation transaction address 530 to the customer device 102. The customer device 102 can then transact from the multi-confirmation transaction address 530 using the appropriate number of private transaction keys. In an 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 (and transferred to the customer device 102) can preferably be used to transact from the multi-confirmation transaction address 530. The private transaction key 226A at the trusted third party 106 (along with the private transaction key 216A of 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] 6 is a flow diagram illustrating a method 600 for generating a multi-confirmation transaction address 530. Method 600 may be performed by the currency conversion system 104. Method 600 may be performed whenever a new transaction address is needed in a customer wallet. In an example, method 600 may be 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, this may be performed in response to a customer request to create a new multi-confirmation transaction address 530 to store remaining cryptocurrency after a 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 can include the customer's name, date of birth, driver's license number and expiration date, address, phone number, email address, social security number, an image of the customer's government issued photo identification, a photo of the customer holding the government issued photo identification, employment information, and / or income. The identity data can also include biometric data, such as fingerprint data (e.g., a scan of the customer's fingerprint), retina 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). In lieu of raw biometric data (e.g., an image and / or a recording), the identity data can include processed data derived from the raw biometric data, e.g., image features, voice features, etc.

[0098]

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

[0099]

[0129] Optionally, the currency conversion system 104 may determine 604 a first public key derived from the first parent public key. In an example, the currency conversion system 104 may receive the public transaction key 207A from the customer device 102, which 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 may be the public transaction key 207A from the node tree 200A stored on the customer device 102, and the first parent public key may be the public account key 205 or the private account key 204.

[0100]

[0130] Optionally, the currency conversion system 104 may also determine 606 a second public key (e.g., a public transaction key 217 in the node tree 200B stored in the currency conversion system 104) derived from the second parent public key. In an example, the currency conversion system 104 may derive the public transaction key 217 from the node tree 200B stored in the currency conversion system 104. In an example, the public transaction key 217 is derived from a public account key 215 that is derived from a master public key 213 that is optionally derived from a master private key 212. Alternatively, the public transaction key 217 may be derived from a private account key 214 that is derived from the master private key 212. Alternatively, the public transaction key 217 may be derived from a public account key 215 that is derived from a private account key 214 that is derived from the master private key 212. Thus, the second parent public key may be a public account key 215, a master public key 213, a master private key 212, or a 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 608 a third public key derived from the third parent public key. In an example, the currency conversion system 104 may derive the public transaction key 227 from the public account key 225 that is optionally derived from the master public key 223 previously received from the trusted third party 106. Alternatively, the currency conversion system 104 may derive the public transaction key 227 from the master public key 223 previously received from the trusted third party 106. In other words, the third public key may be the public transaction key 227 and the third master key may be the master public key 223 or the public account key 225, respectively.

[0102]

[0132] The currency conversion system 104 may also derive 610 a multi-confirmation transaction address 530 from a first public key derived from a first parent public key using a hash function (e.g., pay-to-script hash (P2SH) as defined in BIP16 or other public key scripts), 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. The multi-confirmation 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 transact from the multi-confirmation transaction address 530.

[0103]

[0133] The currency conversion system 104 can send 612 the multi-confirmation 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 transact from the multi-confirmation transaction address 530 using the private transaction key associated with at least two of the public transaction keys 207A, 217A, 227A. In an 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 be used to transact from the multi-confirmation transaction address 530 in general. Alternatively, 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 can be used to transact from the multi-confirmation transaction address 530 during restoration of the customer wallet.

[0104]

[0134] 7A is a flow diagram illustrating an example method 700A for cryptocurrency transactions in a multi-acceptance system, such as, for example, using cryptocurrency for goods or services. Method 700A may be performed by customer device 102, currency conversion system 104, and optionally trusted third party 106 in system 100 shown in FIG.

[0105]

[0135] The system 100 may optionally distribute 702 one or more first private transaction keys 206 to the customer device 102, one or more second private transaction keys 216 to the currency conversion system 104, and one or more third private transaction keys 226 to the trusted third party 106. In an example, the private transaction keys 206, 216, 226 may be derived from the respective private account keys 204, 214, 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, the customer can open 704 an application on the customer device 102 using authentication data. In an example, the authentication data may include biometric data, e.g., the customer placing a finger on a fingerprint reader, pointing a camera at their face, pointing a camera at their eye, or speaking into a microphone. In an example, the application may open (or allow certain access) only 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 gained access to the application, the customer can create 706 a transaction request in the application.

[0107]

[0137] The transaction request may indicate the type and amount of cryptocurrency to be transferred, for example, 0.15 Bitcoin. The transaction request may include conditional triggers. The transaction request may also indicate optional attributes such as the amount of cryptocurrency to be transferred, the duration of the transaction request, etc. The transaction request may also include a transaction address of a wallet to which the cryptocurrency should be transferred.

[0108]

[0138] The transaction request may be signed 708 based on the first private transaction key 206 and the second private transaction key 216. Specifically, the application on the customer device 102 may 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 may identify multiple multi-confirmation transaction addresses 530 with sufficient cumulative cryptocurrency to satisfy the transaction request. The application then inputs the first private transaction key 206 and the second private transaction key 216 of each identified multi-confirmation transaction address 530 into a redemption script (e.g., a redemption script according to BIP16) for transacting from the respective multi-confirmation transaction address 530.

[0109]

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

[0110]

[0140] 7B is a flow diagram illustrating an example method 700B for cryptocurrency transactions in a key split system, such as, for example, using cryptocurrency for goods or services. Method 700B may be performed by customer device 102, currency conversion system 104, and optionally trusted third party 106 in system 100 shown in FIG.

[0111]

[0141] The system 100 can optionally distribute 712 the first private key component to the customer device 102, the second private key component to the currency conversion system 104, and the third private key component to the trusted third party 106. In an example, the private key components may be generated from the private transaction key 206 on the customer device using, for example, polynomial interpolation or Shamir secret sharing. In an example, M / N (e.g., 2 / 3) key components may be required to reconstruct the private transaction key 206 used to sign cryptocurrency transactions from a particular transaction address. In an example, the third private key component is used only in an emergency, such as, 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, the customer can open 714 an application on the customer device 102 using authentication data. In an example, the authentication data can 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 eye, or speaking into a microphone. In an example, the application can only be opened if the biometric data matches the biometric data uploaded during onboarding. Alternatively, the authentication data can be a password, or a combination of biometric data and a password. Once the user has gained access to the application, the customer can create 716 a transaction request in the application.

[0113]

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

[0114]

[0144] The transaction request may be signed 718 based on the first private key component and the second private key component. In a key split configuration, the transaction request may be signed 718 by using two or more key components to reconstruct the private transaction key 206 and then signing the transaction request using the reconstructed private transaction key 206, for example, as described in FIG. 8E.

[0115]

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

[0116]

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

[0117]

[0147] FIG. 8A is a flow diagram illustrating a first exemplary method 800A for signing a transaction request using multisig. Method 800A may be performed by a customer device 102 seeking to transact with cryptocurrency. The customer device 102 may identify 801 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 that cumulatively hold the correct type and at least a sufficient amount of cryptocurrency to satisfy the customer's desired transaction, such as, for example, 0.15 Bitcoin. The one or more multi-confirmation transaction addresses 530 may be created during a cryptocurrency purchase, during a previous cryptocurrency transaction to store remaining cryptocurrency, and / or at the customer's request.

[0118]

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

[0119]

[0149] The customer device 102 may also identify 805 one or more second private transaction keys 216 associated with the one or more multi-confirmation transaction addresses 530. The second private transaction keys 216 may be initially stored in the node tree 200B on the currency conversion system 104 and then transmitted to the customer device 102. In an example, the second private transaction keys 216 may be transmitted to the customer device 102 when the one or more multi-confirmation transaction addresses 530 are funded, for example, during a cryptocurrency purchase, and / or created during a previous cryptocurrency transaction to store leftover cryptocurrency. The second private transaction keys 216 may be hardened (i.e., non-enhanced) keys.

[0120]

[0150] The customer device 102 may sign 807 the transaction request using one or more first private transaction keys 206 and one or more second private transaction keys 216. Signing may include, for example, generating a signed transaction using a redemption script (e.g., in accordance with BIP16) after verifying that the first and second private transaction keys 216 corresponding to each source multi-confirmation transaction address 530 have been entered.

[0121]

[0151] Optionally, the customer device may send 809 a request to the currency conversion system 104 to create a new multi-confirmation transaction address 530 to hold the remaining funds after the transaction. In an 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 may be transferred to the new multi-confirmation transaction address 530 created by the currency conversion system 104.

[0122]

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

[0123]

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

[0124]

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

[0125]

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

[0126]

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

[0127]

[0157] 8C is a flow diagram illustrating a third exemplary method 800C for signing a transaction request using multisig. In method 800C, the customer device 102 may sign 812 the transaction request using a first private transaction key 206A stored on the customer device 102. The customer device 102 may send 814 the partially signed transaction request to the currency conversion system 104. The currency conversion system 104 may sign 816 the transaction request using a second private transaction key 216A stored on the currency conversion system 104. The currency conversion system 104 may send 817 the fully signed transaction request to the customer device 102. 2 can be sent to 818.

[0128]

[0158] FIG. 8D is a flow diagram illustrating a fourth exemplary method 800D for signing a transaction request using multisig. In method 800D, the customer device 102 may send 822 an unsigned transaction request to the currency conversion system 104. The currency conversion system 104 may sign 824 the transaction request using the second private transaction key 216A stored in the currency conversion system 104. Because the transaction may require a signature using two of the three private transaction keys (e.g., two of the private transaction keys 206A, 216A, 226A), the transaction request can only be partially signed at this point. Thus, the currency conversion system 104 may send 826 the partially signed transaction request back to the customer device 102. The customer device 102 may sign 828 the transaction request using the first private transaction key 206A stored in the customer device 102.

[0129]

[0159] FIG. 8E is a flow diagram illustrating a method 800E for signing a transaction request using key splitting. FIG. 8E assumes that the private transaction key has been pre-split into a set of at least two (or three) key components, for example, using polynomial interpolation or Shamir secret sharing. FIG. 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 at 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 832 the biometric data and a request for the second private key component to the currency conversion system 104. The currency conversion system 104 may receive the request, verify that the biometric data matches the customer's stored biometric data, and verify 834 that AML was previously performed for the customer. The currency conversion system 104 may also forward 836 the second private key component to the customer device 102. The customer device 102 may reconstruct 838 a private key using the first private key component (stored on the customer device 102) and the second private key component (received from the currency conversion system 104). The customer device 102 may sign 840 the transaction request using the reconstructed private transaction key. Optionally, the customer device 102 may delete 842 the second private key component and / or the reconstructed private key (received from the currency conversion system 104) immediately after adding the signature to the transaction request.

[0131]

[0161] 9A is a flow diagram illustrating an example method 900A for restoring a customer wallet after loss of a customer key using multisig. Method 900A may be performed by the currency conversion system 104 shown in FIG. 1. Method 900A may be performed in response to a customer losing or destroying a device (e.g., a mobile device) that stored the customer wallet key. Method 900A may also be performed when a customer purchases a new mobile device (i.e., upgrades) or when a customer hard resets / reformats a mobile device.

[0132]

[0162] The currency conversion system 104 may receive 901 customer identity data and a request to restore a customer wallet from a customer device 102. In examples, the 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, an image of the customer's government issued photo identification, a photo of the customer holding the government issued photo identification, employment information, and / or income. The identity data may include fingerprint data (e.g., a fingerprint of the customer). The identity data may also include biometric data such as a fingerprint scan, retina 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 the raw biometric data (e.g., images and / or recordings), the identity data may include processed data derived from the raw biometric data, e.g., image features, voice features, etc.

[0133]

[0163] The currency conversion system 104 may verify 903 the customer identity data received from the customer device 102. In an example, the verification may include comparing the received biometric data to previously stored biometric data, for example, biometric data stored when the customer initially 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 the previously stored biometric data), the currency conversion system 104 may communicate 905 a request for a first key associated with the customer wallet to a key repository of the trusted third party 106. In an example, the first key may be the private transaction key 226 stored in the trusted third party 106.

[0135]

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

[0136]

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

[0137]

[0167] 9B is a flow diagram illustrating another example method 900B for restoring a customer wallet after loss of a customer key using multisig. Method 900B may be performed by the currency conversion system 104 shown in FIG. 1. Method 900B may be performed in response to a customer losing or destroying a device (e.g., a mobile device) that stored the customer wallet key. Method 900B may also be performed when a customer purchases a new mobile device (i.e., upgrades) or when a customer hard resets / reformats a mobile device.

[0138]

[0168] The currency conversion system 104 may receive 902 customer identity data and a request to restore a customer wallet from a 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, an image of the customer's government issued photo identification, a photo of the customer holding the government issued photo identification, 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 fingerprint), retina 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., an image and / or a recording), the identity data may include processed data derived from the raw biometric data, e.g., image features, voice features, etc.

[0139]

[0169] The currency conversion system 104 receives the customer identity from the customer device 102. The identity data may be verified 904. In an example, the verification may include comparing the received biometric data to previously stored biometric data, for example, biometric data stored when the customer initially created an account with 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 the previously stored biometric data), the currency conversion system 104 can identify 906 one or more populated multi-confirmation transaction addresses 530 in the customer wallet, i.e., one or more multi-confirmation transaction addresses 530 in which the cryptocurrency is included. This may include 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 may maintain an index of the last multi-confirmation transaction address 530 (associated with the private account key 214) that was generated and / or populated for the customer.

[0141]

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

[0142]

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

[0143]

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

[0144]

[0174] FIG. 9C is a flow diagram illustrating an example method 900C for restoring a customer wallet after loss of a customer's key component using key splitting. Method 900C may be performed by the currency conversion system 104 shown in FIG. 1. Method 900C may be performed in response to a customer losing or destroying a device (e.g., a mobile device) that stored the customer's wallet key component. Method 900C may be performed when a customer purchases a new mobile device (i.e., upgrades) or when a customer upgrades a mobile device. It can also be executed when you hard reset / reformat the device.

[0145]

[0175] The currency conversion system 104 may receive 916 customer identity data and a request to restore the customer wallet 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, an image of the customer's government issued photo identification, a photo of the customer holding the government issued photo identification, 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 fingerprint), retina 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). In lieu of raw biometric data (e.g., an image and / or a recording), the identity data may include processed data derived from the raw biometric data, e.g., image features, voice features, etc.

[0146]

[0176] The currency conversion system 104 may verify 918 the customer identity data received from the customer device 102. In examples, the verification may include comparing the received biometric data to previously stored biometric data, for example, biometric data stored when the customer initially 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 the previously stored biometric data), the currency conversion system 104 can identify 920 one or more deposited transaction addresses 530 in the customer wallet, i.e., one or more multi-confirmation transaction addresses 530 in which the cryptocurrency is included. This may include traversing the transaction addresses 530 in the customer wallet. Alternatively, the currency conversion system 104 may maintain an index of the last transaction address 530 generated and / or deposited for the customer.

[0148]

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

[0149]

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

[0150]

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

[0151]

[0181] FIG. 10A is a block diagram illustrating an example method 1000A for restoring a customer wallet using multisig. FIG. 10A illustrates one implementation of element 909 of FIG. 9A. The method 1000A may be performed by one or more of the customer device 102, the currency conversion system 104, and / or the trusted third party 106 shown in FIG.

[0152]

[0182] Method 1000A may be performed after a customer loses, destroys, upgrades, or hard resets / reformats a customer device 102 that owns the private key associated with the customer wallet. The process of restoring a customer wallet (i.e., an 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 (e.g., as described in FIG. 3). The term "new" when referring to a key, address, or customer wallet means that the key, address, or wallet was created during restoration of an account following the loss of one or more old keys, addresses, or wallets.

[0154]

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

[0155]

[0185] One of the devices generating the new private key (e.g., the currency conversion system 104) may also generate 1003 a new transaction address associated with the new customer wallet based on the new private key. This may include generating a new public key associated with the new private key and deriving a new transaction address from the new public key. In an example, a hash function may receive three new public keys (e.g., one each from the customer device 102, the currency conversion system 104, and the 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] The digital assets may also be transferred 1005 from the old (lost) customer wallet to the new transaction address, for example, using a first key (from the trusted third party 106) and a second key (from the currency conversion system 104) to sign the transaction. 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 a change of ownership from the old customer wallet to the new transaction address. The request to record a change of ownership may require a signature using M / N (e.g., 2 / 3) of the new private key, or M / N (e.g., 2 / 3) of the old private key. Thus, the device generating or sending the request must verify that it already owns one or more old private keys and / or has received one or more old private keys from other devices before signing the request, i.e., the generating / sending device must verify that it owns M / N (e.g., 2 / 3) of the old private keys before signing the request.

[0157]

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

[0158]

[0188] FIG 10B is a block diagram illustrating another example method 1000B for restoring a customer wallet using multisig. FIG 10B illustrates one implementation of element 912 of FIG 9B. Method 1000B may be performed by one or more of customer device 102, currency conversion system 104, and trusted third party 106 shown in FIG 1.

[0159]

[0189] Method 1000B may be performed after a customer loses, destroys, upgrades, or hard resets / reformats a customer device 102 that owns 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 a transaction address associated with the old account key to a transaction address associated with the new account key.

[0160]

[0190] Optionally, new public account keys 205, 215, 225 may be generated 1002 for each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Since method 1000B is likely to be performed after loss of the customer's private account key 204 (and public account key 205) in the old customer device 102, the new customer device 102 may generate a new public account key 205, for example, from the new private account key 204. The currency conversion system 104 may 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 may also generate a new public account key 225 for the trusted third party 106 using the master public key 223 stored in the currency conversion system 104, for example, with a new index of the master public key 223 stored in the currency conversion system 104. The 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 public transaction key 207 with index zero for the customer device 102, a second public transaction key 217 with index zero for the currency conversion system 104, and a third public transaction key 227 with index zero may be determined 1004. In an example, one or more of the public transaction keys 207, 217, 227 with index zero may be derived at index 0 of the new public account keys 205, 215, 225, respectively. Alternatively, or in addition, one or more of the public transaction keys 207, 217, 227 with index zero may be derived from one or more new private account keys 204, 214, 224, respectively. Alternatively, or in addition, 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 may 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 the respective node trees 200A, 200B, 200C.

[0162]

[0192] The currency conversion system 104 may also generate 1006 a multi-confirmation transaction address 530 with index zero from the public transaction key 207, 217, 227 with index zero. This may involve generating 1006 two private tokens with index zero for use in transacting from the multi-confirmation transaction address 530 using a hash function (e.g., a pay-to-script hash (P2SH) or other public key script). This includes creating a multi-confirmation transaction address 530 that requires the transaction key 206, 216, 226.

[0163]

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

[0164]

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

[0165]

[0195] FIG 10C is a block diagram illustrating an example method 1000C for restoring a customer wallet using key splitting. FIG 10C illustrates one implementation of element 926 in FIG 9B. Method 1000C may be performed by one or more of customer device 102, currency conversion system 104, and trusted third party 106 shown in FIG 1.

[0166]

[0196] Method 1000C may be performed after a customer loses, destroys, upgrades, or hard resets / reformats a customer device 102 that possesses a private key component associated with a customer wallet. The process of restoring a customer wallet (i.e., an old customer wallet) includes 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 may be generated 1014, e.g., new public account key 205, at the customer device 102. As method 1000C is likely to be performed after loss of the customer's private account key 204 (and public account key 205) at the old customer device 102, the new customer device 102 may generate a new public account key 205, e.g., from the new private account key 204.

[0168]

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

[0169]

[0199] The transaction address at index zero may be generated 1018 from the public transaction key 207 at index zero. This may involve using a hash function (e.g., The process includes using a private key script (such as a sudo ...

[0170]

[0200] One or more first private key components from the trusted third party 106 and one or more second private key components from the currency conversion system 104 may be used to reconstruct 1020 one or more private transaction keys 206.

[0171]

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

[0172]

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

[0173]

[0203] Figure 11 is a block diagram illustrating an example system 1100 for transacting from a multi-confirmation transaction address 530. The system 1100 may be complementary to the currency conversion system 104 shown in Figure 5 and may transact from a multi-confirmation transaction address 530 using M of N (e.g., 2 / 3) private transaction keys 206A, 216A, 226A. The system 1100 may be implemented in the customer device 102 or the currency conversion system 104, depending on the application.

[0174]

[0204] Specifically, for routine cryptocurrency transactions, the system 1100 may be implemented on the customer device 102. In an example, the system 1100 may receive the private transaction key 216A (at index X of the customer's private account key 214) from the currency conversion system 104. The system 1100 may input the private transaction key 216A and the private transaction key 206A (also at index X of the private account key 204 on the customer device 102) into a redemption module 1140. The redemption module 1140 may verify that both the private transaction key 206A and the private transaction key 216A correspond to the same multi-confirmation transaction address 530. If both the private transaction key 206A and the private transaction key 216A correspond to the multi-confirmation transaction address 530, the redemption module 1140 may generate a signed transaction 1142. In other words, the system 1100 may allow cryptocurrency at the multi-confirmation transaction address 530 to be transferred to another transaction address, e.g., specified by a customer on the customer device 102. The redemption module 1140 may generate a signed transaction 1142 using a redemption script (e.g., in accordance with BIP16).

[0175]

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

[0176]

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

[0177]

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

[0178]

[0208] Each of the devices in system 1200 may be communicatively coupled to one or more other devices using at least one network 112 (e.g., networks 112A-B). In an example, at least one network 112 includes at least one wired network and / or at least one wireless network. In an example, any combination of wired and wireless networks may be used to couple customer device 102, vault system 1250, and optional record-keeping system 1252 to one another. In an 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 an example, any combination of a local area network, a wide area network, or the Internet may be used as at least one network 112 to couple customer device 102, vault system 1250, and optional record-keeping system 1252 to one another.

[0179]

[0209] The system 1200 can use a multi-approval methodology, e.g., a multi-party multi-signature (multisig) methodology, a multi-party key splitting methodology, or a combination of the two. If multisig is used, the N private keys can be generated, for example, at the customer device 102, at the vault system 1250, or some combination. Alternatively, if key splitting is used, the private keys can be generated at the customer device 102, at the vault system 1250, or some combination. In one embodiment, a private key is generated at one of the vault systems 1250, and then the private key is split into N key components, each stored at a different vault system 1250 or customer device 102. Alternatively, system 1200 may use a combination of multi-sig and key splitting methodologies, where, for example, N private keys are generated (at the customer device 102 and / or vault system 1250) and at least one of the private keys is split into various key components that must be reconstructed before being used to sign a transaction.

[0180]

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

[0181]

[0211] During onboarding with 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, the identity data can include personally identifiable information such as, for example, the customer's name, date of birth, driver's license number and expiration date, address, telephone number, email address, social security number, an image of the customer's government-issued photo identification, a photo of the customer holding the government-issued photo identification, employment information, and / or income. The identity data can also include biometric data such as fingerprint data (e.g., a scan of the customer's fingerprint), retina 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., an image, a recording, etc.), the application can transmit only processed data derived from the raw biometric data, e.g., image features, voice features, etc. In addition to identity data, the customer device 102 may also transmit a private key (or key components) for the vault system 1250 to store, for example, in its key repository.

[0182]

[0212] It should be noted that alternative onboarding configurations are possible in which (1) the customer device 102 sends 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). Whether the vault system 1250 receives the private key (or key component) from the customer device 102 or the vault system 1250 generates the private key (or key component), the vault system 1250 can associate the private key (or key component) with the customer at 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 a distributed ledger (or a node 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) where 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, the customer may adjust the configuration used based on security, reliability, cost, and / or other concerns. In one example, the customer may require 3 of 4 private keys (or key components) and perform actions on personal accounts with 1 of 4 private keys (or key components) initially stored on the customer device 102 itself (e.g., (M=3)<(N=4)). Such a configuration may be used, for example, for accounts over which the customer wishes to retain a high degree of control, since (1) more people would need to collude to steal funds from the account and (2) all private keys (or key components) do not exist outside the customer device 102. In other words, a 3 / 4 configuration may reduce the likelihood of theft of account funds (e.g., compared to a 2 / 4 or 2 / 5 configuration and / or a configuration that does not initially store private keys (or key components) on the customer device 102 itself).

[0186]

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

[0187]

[0217] Furthermore, a customer may have multiple accounts, e.g., personal, business, family, etc. Thus, the customer may tailor digital security differently for two different accounts. For example, the customer may only need 2 of 3 private keys (or key components) to perform actions on a personal account (e.g., (M=2)<(N=3)), while needing 4 of 4 private keys (or key components) to perform actions on a business account (e.g., (M=4)=(N=4)). Furthermore, the customer may choose to initially store 1 of N private keys (or key components) on the customer device 102 for one account, while not initially storing any of N private keys (or key components) for another account.

[0188]

[0218] Thus, if desired, Customer may adjust / select (1) the values ​​of M and / or N and / or (2) the specific storage locations of the N private keys (or key components) based on security, reliability, cost, and / or other considerations.

[0189]

[0219] Once a customer selects how many and which vault systems 1250 (and optionally the customer device 102 itself) they wish to store the N private keys (or key components), the customer device 102 can then communicate with the selected vault systems 1250 (e.g., during onboarding and thereafter) via an API. Additionally, the customer device 102 and / or vault systems 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 a record of which vault systems 1250 store a given customer's private key (or key component). The record-keeping system 1252 may be co-located with one of the vault systems 1250. In an example, the record-keeping system 1252 may be located on the currency conversion system 104, which may or may not be the vault system 1250 that stores the customer's private key (or key component).

[0191]

[0221] System 1200 may include N vault systems 1250A-N, where N is 1 or greater. Each vault system 1250 may maintain a key repository 117A-N for storing keys (e.g., a database and / or secure memory) associated with a respective customer. The key repository 117 of each vault system 1250 may be physically located on the same or a different device that performs other functions for the respective 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), currency conversion system 104 (e.g., a bank or a non-bank financial institution that converts currency to another form of currency), business, individual, etc. In an example, vault systems 1250 may each send a private key (or key components) to customer device 102 (in response to a request from customer device 102) to generate a transaction address or wallet recovery, but vault systems 1250 preferably do not generate transaction addresses, sign transactions, or optionally send transactions to distributed ledger 118 themselves. In such an example, vault system 1250 may not be required to hold a money transmitting license under applicable rules and regulations. However, alternative configurations are possible in which one or more vault systems 1250 generate transaction addresses, sign transactions, send transactions, and / or hold a money transmitting license.

[0193]

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

[0194]

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

[0195]

[0225] In a second authentication configuration, the identity service provider 110 (rather than the vault system 1250) may store the customer's identity data. The second configuration may be preferred over the first configuration because the vault system 1250 does not implement an authentication system, does not implement AML / KYC for the customer, and does not store the customer's identity data. Optionally, the customer wallet provider may implement AML / KYC for the customer.

[0196]

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

[0197]

[0227] Once the customer device possesses at least M of the N private keys (or key components), the customer device 102 may perform at least one action based on (e.g., requiring) the at least M of the N private keys (or key components). Examples of the action may 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, for example, during customer wallet restoration. In a key splitting configuration, the action may include the customer device 102 reconstructing a private key from the at least M (or N) private key components. Additionally, although at least 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 a transaction to the optional distributed ledger 118, for example, to a node implementing the optional distributed ledger 118.

[0198]

[0228] In a configuration in which private keys (or key components) are used to encrypt or decrypt data, the customer device 102 and / or at least one vault system 1250 may generate N private keys (or key components). In a multisig configuration, the N private keys may be generated at the customer device 102 and / or at least one vault system 1250. In a key split configuration, a single private key is generated (at the customer device 102 or at least one vault system 1250) and split into N private key components. The N different private keys (or key components) may be used to encrypt or decrypt data. Each may be distributed to a different one of at least one vault system 1250 and / or the customer device 102 itself, for example, during an onboarding process performed between the different vault systems 1250 and the customer device 102. The customer device 102 may then request and receive at least M of the N private keys (or key components), e.g., the M private keys (or key components) may be transmitted from the at least one vault system 1250 after authentication. Optionally, the customer device 102 may store one of the N private keys (or key components) locally and distribute only the N-1 private keys (or key components) to the N-1 respective vault systems 1250.

[0199]

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

[0200]

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

[0201]

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

[0202]

[0232] In an example, the data to be encrypted and / or decrypted may be a non-monetary cryptographic token (e.g., associated with a customer's identity data), a security token (e.g., representing ownership of an asset), an audio file, a video file, a text file, or any other digital object, file, and / or token. In an example, the encryption and / or decryption may be part of a federated service in which the vault system 1250 receives a fee for storing a customer's private key (or key component) and / or for transmitting the private key (or key component) to the customer, respectively. Optionally, the customer device 102 may delete at least one (e.g., all) of the locally stored private keys (or key components) after encrypting and / or decrypting the data.

[0203]

[0233] In a configuration in which a private key (or key component) is used to generate a transaction address based on N private keys (or key components), the customer device 102 and / or at least one vault system 1250 may generate the 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 The device 102 may split a single private key into N private key components prior to distribution. Optionally, the customer device 102 may store 1 of the N private keys (or key components) locally and distribute only the N-1 private keys (or key components) to the N-1 respective vault systems 1250.

[0204]

[0234] In a multisig example, the customer device 102 may generate a transaction address after obtaining or deriving N public transaction keys (or key components). In a multisig example, each public transaction key may be derived from each of the N private keys (or key components), with each public transaction key derived (1) directly from a private account key received from the vault system 1250 or stored locally on the 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 the customer device 102. As noted above, receiving a private key from the vault system 1250 may include a direct authentication process (between the customer device 102 and the vault system 1250) or an indirect authentication process (performed via the identity service provider 110). Generating the transaction address may include using a multi-approval hash module 528 operating on the customer device 102, for example utilizing a pay-to-script hash (P2SH) as defined in BIP16, or other public key script described in connection with Figure 5. In addition to the public transaction key, the multi-approval hash module 528 may optionally receive multi-approval conditions 529 that specify, for example, that M out of N private keys are required to sign a transaction from the generated transaction address. The N public transaction keys (along with the multi-approval conditions 529) may then be used as inputs to the multi-approval hash module 528 to generate a transaction address.

[0205]

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

[0206]

[0236] After the transaction address is generated, funds can be received at the generated transaction address, at which point the customer device 102 can send the sweep transaction to the optional distributed ledger 118 (or to 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 a transaction using M private keys (or key components), the customer device 102 and / or at least one vault system 1250 generates N private keys (or key components) and distributes them to the customer device 102 and / or at least one vault system 1250. In a key splitting configuration, the customer device 102 may split a single private key into N private key components before distribution. After an onboarding process performed between the 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, a direct authentication process (between the customer device 102 and the vault system 1250) or an indirect authentication process (performed via the identity service provider 110). Optionally, the customer device 102 may store 1 of the N private keys (or key components) locally and only transmit the N-1 private keys (or key components) to each of the N-1 vault systems 102. It will be distributed to 250.

[0208]

[0238] In a multisig example, once the customer device 102 possesses the required M of N private keys, it can sign a transaction from a transaction address that requires the M of N private keys. Signing the transaction may include using a redemption module 1140 operating on the customer device 102. In an example, the redemption module may utilize a redemption script (e.g., in accordance with BIP16) to generate a signed transaction 1142, e.g., as described in connection with FIG. 11 . In an example, a respective private transaction key may be derived from each of the M private account keys (or key components), each derived from a respective private account key received from the vault system 1250 and optionally stored locally on the customer device 102. The M private transaction keys (along with the transaction address) may be used as inputs to the redemption module 1140 to generate the signed transaction. In an example of key splitting, a private transaction key can be derived from a single private account key that is reconstructed from M out of N private key components, and then a signed transaction can be generated based on the private transaction key and the transaction address.

[0209]

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

[0210]

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

[0211]

[0241] 13 is a flow diagram illustrating an example method 1300 for performing actions based on at least M of N private keys (or key components), e.g., encrypting and / or decrypting data, generating transaction addresses, signing transactions, etc. Method 1300 may be performed by customer device 102 and / or at least one vault system 1250 in system 1200 of FIG.

[0212]

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

[0213]

[0243] In an example, a transaction indicating the generation and / or transmission of a private key (or key component) may be recorded (or transmitted for recording) in the optional distributed ledger 118 by the device / system generating the private key (or key component). In an example, the customer device 102 or vault system 1250 generating the private key (or key component) may transmit a hash of the private key (or key component) to the distributed ledger (or a node implementing the optional distributed ledger 118) to serve as proof of creation of the private key (or key component). In an 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 1304 a request for the customer's identity data and respective private keys (or key components). In a first authentication configuration, the vault system 1250 stores the identity data directly. In the first authentication configuration, each key request can also include identity data that each vault system 1250 can use for the customer. In a second configuration, the customer device 102 can send the identity data to the identity service provider 110 (rather than 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 request can be transferred using a secure transfer protocol.

[0215]

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

[0216]

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

[0217]

[0247] The customer device 102 may also perform 1310 at least one action based on the at least M of N private keys (or key components). In an example, the action may include performing 1310 an action based on the at least M of N private keys (or key components) and / or performing 1310 an action based on the at least M of N private keys (or key components). At least M of N keys derived from are required. Examples of this action may 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) signing a transaction, e.g., a sweep transaction during restoration of a customer wallet, using at least M of N private keys (or key components). These actions are described in more detail below.

[0218]

[0248] In a key splitting configuration, the actions may include the customer device 102 reconstructing a private key from at least M private key components. Additionally, 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 a transaction to the optional distributed ledger 118, e.g., to a node implementing the optional distributed ledger 118.

[0219]

[0249] 14 is a flow diagram illustrating an example method 1400 for encrypting or decrypting data based on at least M of N private keys (or key components). Method 1400 may be performed by at least customer device 102 in system 1200 of FIG. 12. Method 1400 may be an example of actions performed at step 1310 of method 1300 shown in FIG.

[0220]

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

[0221]

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

[0222]

[0252] Optionally, the customer device 102 may also delete 1406 at least one of the private keys (or key components). In an example, the customer device 102 may only delete a private key (or key component) that was received from the vault system 1250, but not, for example, a private key (or key component) that was optionally initially stored on the customer device 102.

[0223]

[0253] 15 is a flow diagram illustrating an example method 1500 for generating a transaction address at a customer device 102. Method 1500 may be performed by at least a customer device 102 in system 1200 of FIG. 12. Method 1500 may be an example of actions performed at step 1310 of method 1300 shown in FIG.

[0224]

[0254] Optionally, customer device 102 can determine 1502 at least M of N private keys (or key components), including receiving at least a portion of the at least M of 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 vault system 1250. Alternatively, all of the N private keys (or key components) may be stored across vault systems 1250, e.g., one private key (or key component) per vault system 1250.

[0225]

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

[0226]

[0256] In an example of key splitting, 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 may be used as an input (e.g., to a hashing module) to generate a transaction address, e.g., without a multi-confirmation condition. In an example, only the reconstructed private key may be required for transactions from the generated transaction address.

[0227]

[0257] Optionally, the customer device 102 may also receive 1506 funds to the transaction address as part of the transaction. Optionally, the customer device 102 may also send the completed transaction to the optional distributed ledger 118 for recording. More specifically, the customer device 102 may send the completed transaction 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 flow diagram illustrating an example method 1600A for signing a transaction using at least M of N private keys (or key components). Method 1600A may be performed by at least a customer device 102 (and optionally at least one vault system 1250) in system 1200 of Figure 12. Method 1600A may be an example of actions performed at step 1310 of method 1300 shown in Figure 13.

[0229]

[0259] Optionally, the customer device 102 may determine 1602 at least M of the N private keys (or key components). The method may include receiving at least a portion of at least M of N private keys (or key components) from vault systems 1250, and optionally identifying locally stored private keys (or key components) that were not previously stored in vault system 1250. Alternatively, all of the N private keys (or key components) may be stored across vault systems 1250, e.g., one private key (or key component) per vault system 1250.

[0230]

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

[0231]

[0261] The transaction may also be signed 1606 using at least M of N private keys (or key components). In a first signing configuration, the customer device 102 may sign the transaction using at least M of N private keys (or key components) received from the respective vault system 1250 and, optionally, locally stored private keys (or key components) not previously stored in the vault system 1250. Signing the transaction may include using a redemption module 1140 operating on the customer device 102. In an example, the redemption module may utilize a redemption script (e.g., in accordance with BIP16) to generate a signed transaction 1142, e.g., as described in connection with FIG. 11. In a multisig example, a respective 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. At least M of N private transaction keys (along with the transaction address) can be used as inputs to the redemption module 1140 to generate a signed transaction. In an example of key splitting, the private transaction key can be derived from a single private account key reconstructed from at least M of N private key components, and then a signed transaction can be generated based on the private transaction key and the transaction address.

[0232]

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

[0233]

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

[0234]

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

[0235]

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

[0236]

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

[0237]

[0267] The transaction may also be signed 1616 using at least M of N private keys (or key components). In a first signing configuration, the customer device 102 may sign the transaction using private keys (or key components) received from the respective vault system 1250 and, optionally, locally stored private keys (or key components) not previously stored in the vault system 1250. Signing the transaction may include using a redemption module 1140 operating on the customer device 102. In an example, the redemption module may utilize a redemption script (e.g., in accordance with BIP16) to generate a signed transaction 1142, e.g., as described in connection with FIG. 11. In a multisig example, the respective private transaction keys are 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. The at least M of N private transaction keys (along with the transaction address) may be used as inputs to the redemption module 1140 to generate the signed transaction. In an example of key splitting, a private transaction key can be derived from a single private account key that is reconstructed from at least M of N private key components, and then a signed transaction can be generated based on the private transaction key and the transaction address.

[0238]

[0268] In a second signing configuration, customer device 102 may repeatedly send the generated transaction to (and receive the transaction from) different vault systems 1250 for signing until the generated transaction is signed with at least M of N private keys. In an example, customer device 102 may send the transaction to a first vault system 1250 for signing and receive the transaction from (and signed by) the first vault system 1250. The external device may receive a transaction (signed by the second vault system 1250), then send the transaction to the second vault system 1250, receive 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 components) 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 components) that was not previously stored in the vault system 1250.

[0239]

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

[0240]

[0270] 16C is a flow diagram illustrating an example method 1600C for signing a sweep transaction using at least M of N private keys (or key components) at a customer device 102. Method 1600C may be performed by at least a customer device 102 in system 1200 of FIG. 12. Method 1600C may be an example of actions performed at step 1310 of method 1300 shown in FIG.

[0241]

[0271] Optionally, customer device 102 may determine 1622 at least M of N private keys (or key components), including receiving at least a portion of the at least M of 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 vault system 1250. Alternatively, all of the N private keys (or key components) may be stored across vault systems 1250, e.g., one private key (or key component) per vault system 1250.

[0242]

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

[0243]

[0273] The sweep transaction may also be signed 1626 using at least M of the N private keys (or key components). In an example, the customer device 102 may sign the sweep transaction using at least one private key (or key component) received from the respective vault system 1250, and optionally a locally stored private key (or key component) not previously stored in the vault system 1250. Signing the sweep transaction may include using a redemption module 1140 operating on the customer device 102. In an example, the redemption module may utilize a redemption script (e.g., in accordance with BIP16) to generate a signed sweep transaction 1142, e.g., as described in connection with FIG. 11 . In a multisig example, each private transaction key may be signed 1626 using at least M of the N private keys (or key components) received from the vault system 1250. A private transaction key may be derived from each of the at least M private account keys and optionally stored locally on the customer device 102. The at least M of N private transaction keys (along with the transaction address) may be used as inputs to the redemption module 1140 to generate a signed sweep transaction. In an example of key splitting, the private transaction key may be derived from a single private account key reconstructed from the at least M of N private key components, after which a signed sweep transaction may be generated based on the private transaction key and the transaction address.

[0244]

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

[0245]

[0275] In examples, the devices and systems herein are implemented using memory and / or a processor. In examples, memory can be any device, mechanism, or populated data structure used to store information. In examples, memory can be or include any type of volatile, non-volatile, and / or dynamic memory. In 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 (compact disks, DVDs, Blu-ray disks, etc.), 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. Additionally, one skilled in the art will recognize many additional devices and techniques for storing information that can be used as memory. Memory can be used to store instructions for executing one or more applications or modules on a processor. In an example, the memory may be used in one or more examples to contain all or a portion of the instructions necessary to perform any of the functions of the system devices described herein. The processor may be any known processor, such as a general purpose processor (GPP) or special purpose (such as a field programmable gate array (FPGA), application specific integrated circuit (ASIC), or other integrated circuit or circuit configuration), or any programmable logic device.

[0246]

[0276] The techniques introduced herein can be embodied as dedicated hardware (such as circuitry), as programmable circuitry suitably programmed with software and / or firmware, or as a combination of dedicated and programmable circuitry. Thus, the embodiments can include a machine-readable medium having stored thereon instructions that can be used to program a computer (or other electronic device) to perform a process. The machine-readable medium can include, for example, a floppy disk, an optical disk, a compact disk read-only memory (CD-ROM), a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic or optical card, a flash memory, or any other type of media / machine-readable medium suitable for storing electronic instructions.

[0247] Computer System Overview

[0277] The embodiments of the present disclosure include various steps and operations described above. These various steps and operations may be performed by hardware components or may be implemented by a number of different hardware components. The steps are embodied in machine-executable instructions that are used to cause a general-purpose or special-purpose processor programmed with the instructions to execute the steps. Alternatively, the steps may be executed by a combination of hardware, software, and / or firmware. Thus, FIG. 17 is a block diagram illustrating an exemplary computer system 1700 that may utilize embodiments of the present disclosure. 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] The at least one processor 1704 may be any known processor. The at least one communication port 1706 may be or include, for example, 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 the at least one communication port 1706 may be selected depending on the network, such as a local area network (LAN), a wide area network (WAN), or any network to which the computer system 1700 connects. The at least one main memory 1708 may be a random access memory (RAM) or any other dynamic storage device commonly known in the art. The at least one read-only memory 1712 may be any static storage device, such as a programmable read-only memory (PROM) chip for storing static information, such as instructions for the at least one processor 1704.

[0249]

[0279] At least one mass storage device 1714 can be used to store information and instructions. For example, a hard disk (such as a magnetic disk drive or 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 mass storage device can be used. The interconnect 1702 can be or include one or more buses, bridges, controllers, adapters, and / or point-to-point connections. The interconnect 1702 communicatively couples the at least one processor 1704 with 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. The at least one removable storage medium 1710 can be any type of external hard drive, floppy drive, compact disk read only memory (CD-ROM), compact disk rewritable (CD-RW), digital video disk read only memory (DVD-ROM), Blu-ray disk read only memory (BD-ROM), Blu-ray disk writeable (BD-R), Blu-ray disk writeable erasable (BD-RE).

[0250]

[0280] The above components are intended to illustrate some types of possibilities. The foregoing examples are merely exemplary embodiments and should not limit the present disclosure in any way.

[0251]

[0281] 18 is a block diagram illustrating another exemplary computing device 1800. The exemplary computing device 1800 may 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 vault 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, optionally at least one network interface 1806, an optional display device 1808, optional input devices 1810, and an optional network interface 1812. Includes optional power supply 1812.

[0252]

[0282] In an example, the at least one memory 1802 may be any device, mechanism, or populated data structure used to store information. In an example, the at least one memory 1802 may be or include any type of volatile, non-volatile, and / or dynamic memory. In an example, the at least one memory 1802 may 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, the 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. Additionally, one skilled in the art will recognize many additional devices and techniques for storing information that may be used as the at least one memory 1802. The at least one memory 1802 may be used to store instructions for executing one or more applications or modules on the at least one processor 1804. In an example, the at least one memory 1802 may be used in one or more examples to accommodate all or a portion of the instructions necessary to perform the functions discussed herein, for example, in FIGS. 3-4 and 6-10.

[0254]

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

[0255]

[0285] In an example, the 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 the system 100). In an example, the at least one optional network interface 1806 includes at least one of an Ethernet interface, a cellular radio access technology (RAT) radio, a Wi-Fi radio, a Bluetooth radio, or a near field communication (NFC) radio. In an example, the at least one optional network interface 1806 includes a cellular radio access technology radio configured to establish a sufficient speed cellular data connection (mobile internet) with a remote server using a local area network (LAN) or a wide area network (WAN). By way of example, cellular radio access technologies may include Personal Communications Services (PCS), Special Mobile Radio (SMR) services, Enhanced Special Mobile Radio (ESMR) services, Advanced Wireless Services (AWS), Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM) services, Wideband Code Division Multiple Access (W-CDMA), Universal Mobile Telecommunications System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX), Third Generation Partnership Project (3GPP) Long Term Evolution (LTE), High Speed ​​Packet Access (HSPA), third generation (3G), fourth generation (4G), fifth generation (5G), or the like, or other suitable technologies. In an example, the at least one optional network interface 1806 includes at least one of 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 an example, the at least one optional network interface 1806 includes a near field communication device limited to nearby 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 an example, the optional at least one display device 1808 includes a light emitting diode (LED), a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, an e-ink display, a field emission display (FED), a surface conduction electron emission display (SED), or a plasma display. In an example, the optional at least one input device 1810 includes at least one of a touch screen (including capacitive and resistive touch screens), a touch pad, a capacitive button, a mechanical button, a switch, a dial, a keyboard, a mouse, a camera, a biometric sensor / scanner, a microphone, and the like. In an example, the optional at least one display device 1808 combined with the optional at least one input device 1810 provides a human machine interface (HMI) for user interaction with the customer device 102, the currency conversion system 104, and / or the trusted third party 106. In an example, the at least one optional power supply 1812 is used to provide power to various components of the computing device 1800.

[0257] term

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

[0258]

[0288] The term "determining" may include calculating, computing, generating, processing, deriving, investigating, looking up (e.g., looking up a table, database or another data structure), ascertaining, and the like. "Determining" may also include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. "Determining" may also include resolving, selecting, choosing, establishing, and the like.

[0259]

[0289] The phrase "based on" does not mean "based only on," unless expressly specified otherwise. In other words, the phrase "based on" describes both "based only on" and "based at least on." Furthermore, the phrase "based on" does not exclude intermediate steps, e.g., A is based on C, B is based on C, A is based on B. Furthermore, 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 a direct physical connection or coupling. Thus, for example, two devices may be coupled directly or through one or more intermediary media or devices. As another example, Devices may be coupled such that information can be passed between them without sharing a physical connection. Based on the disclosure provided herein, one of ordinary skill in the art will recognize various ways in which a connection or coupling may exist in accordance with the foregoing definition.

[0261]

[0291] The phrases "in an exemplary embodiment," "in an illustrative embodiment," "in some embodiments," "according to some embodiments," "in an illustrated embodiment," "in another embodiment," "embodiment," "in an example," "example," "in some examples," "some examples," and the like generally mean that the particular feature, structure, or characteristic that follows the phrase is included in at least one embodiment of the present disclosure, and may also be included in more than one embodiment of the present disclosure. Moreover, such phrases do not necessarily refer to the same embodiment or different embodiments.

[0262]

[0292] If the specification states that a component or feature "may," "could," "may" or "might" be included or have a characteristic, that particular component or feature need not be included or have the characteristic.

[0263]

[0293] The term "in response" includes fully or partially responding.

[0264]

[0294] The term "module" refers broadly to a component of software, hardware, or firmware (or any combination thereof). A module is typically a functional component that can use specified inputs to produce useful data or other output. A module may or may not be self-contained. An application program (also called an "application") can contain one or more modules, or a module can 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 be as large as a few personal computers on a local area network (LAN) or as large as the Internet (a worldwide network of computers). As used herein, "network" is intended to encompass any network that can transmit information from one entity to another. In some cases, a network can be made up of multiple networks, even multiple heterogeneous networks interconnected via gateways operable to facilitate communication between the 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 the Public Switched Telephone Network (PSTN).

[0266]

[0296] Also, for purposes of illustration, various embodiments of the present 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 the present disclosure with respect to modern computer networks and programs, the methods and apparatus described herein are equally applicable to other systems, devices, and networks, as will be understood by those skilled in the art. Thus, the illustrated applications of the embodiments of the present disclosure are intended to be exemplary, not limiting. Other systems, devices, and networks to which the embodiments of the present 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. Additionally, the embodiments are applicable to all levels of computing, from personal computers to large network mainframes and servers. It is possible to use.

[0267]

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

[0268] Working Example

[0298] Example 1 includes a computing system comprising at least one processor, at least one memory communicatively coupled to the at least one processor, and 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 configured to receive from the customer device customer identity data and a request to restore a customer wallet, the at least one processor configured to verify the customer identity data received from the customer device, upon the at least one processor verifying the customer identity data received from the customer device, the at least one network interface configured to communicate a request for a first key associated with the customer wallet to a key repository of the trusted third party, and the at least one processor 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, further comprising: when the at least one network interface receives a first key associated with the customer wallet from a 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 a second key associated with the customer wallet.

[0270]

[0300] Example 3 includes the computing system of example 2, wherein 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, at least in part, by 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 the digital assets from the old customer wallet to the new transaction address using the first key and the second key.

[0271]

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

[0272]

[0302] Example 5 includes the computing system of any of Examples 3-4, wherein the 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 the at least one network interface is configured to communicate the one or more new private keys to the customer device.

[0274]

[0304] Example 7 includes the computing system of example 6, wherein the new private key is a private transaction key.

[0275]

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

[0276]

[0306] Example 9 includes the computing system of any of examples 1-8, wherein the identity data comprises biometric data.

[0277]

[0307] Example 10 includes the computing system of any of examples 1-9, wherein the trusted third party is at least one of a credit union or a bank.

[0278]

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

[0279]

[0309] Example 12 includes a system comprising: a computing device configured to communicate with a trusted third party and a customer device of a customer; and a key repository communicatively coupled to the computing device, the computing device configured to receive from the customer device customer identity data and a request to restore a customer wallet, the computing device configured to verify the customer identity data received from the customer device, the computing device configured to communicate a request for a first key associated with the customer wallet to the trusted third party key repository, 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, further comprising: when the computing device receives a first key associated with the 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, where 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, at least in part, by 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 the digital assets from the old customer wallet to the new transaction address using the first key and the second key.

[0282]

[0312] Example 15 includes the system of example 14, wherein the customer wallet includes a plurality of old transaction addresses, each of which is associated with three private keys, and An old transaction address would need at least two of the three private keys associated with each old transaction address in order to access the digital assets of that old transaction address.

[0283]

[0313] Example 16 includes the system of any of Examples 14-15, wherein the computing device is further configured to communicate a new transaction address associated with the 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 the one or more new private keys to the customer device.

[0285]

[0315] Example 18 includes the system of example 17, wherein the new private key is a private transaction key.

[0286]

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

[0287]

[0317] Example 20 includes the system of any of examples 12-19, wherein the identity data comprises biometric data.

[0288]

[0318] Example 21 includes the system of any of Examples 12-20, wherein the trusted third party is at least one of a credit union or a bank.

[0289]

[0319] Example 22 includes the system of any of Examples 12-21, wherein the customer wallet is used to store at least one of securities, currencies, commodities, bonds, funds, or combinations thereof.

[0290]

[0320] Example 23 includes a computerized method comprising: receiving, at a computing device, customer identity data from a customer device and a request to restore a customer wallet, verifying, at the computing device, the customer identity data received from the customer device, and upon verification of the customer identity data received from the customer device, communicating a request to a trusted third party key repository for a first key associated with the customer wallet, and receiving, from the trusted third party key repository, the first key associated with the customer wallet, wherein the customer wallet can be 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, further comprising: restoring the customer wallet at the 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, wherein restoring the customer wallet at the 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 a 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 the digital assets from the old customer wallet to the new transaction address using the first key and the second key.

[0293]

[0323] Example 26 includes the computerized method of example 25, wherein the customer wallet comprises a plurality of old transaction addresses, each old transaction address associated with three private keys, and each old transaction address requires at least two of the three respective private keys associated with the respective old transaction address to access the digital assets of the respective old transaction address.

[0294]

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

[0295]

[0325] Example 28 includes the computerized method of any of Examples 25-27, further comprising communicating the one or more new private keys to the customer device.

[0296]

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

[0297]

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

[0298]

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

[0299]

[0329] Example 32 includes the computerized method of any of Examples 23-31, wherein the trusted third party is at least one of a credit union or a bank.

[0300]

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

Claims

1. At least one processor; at least one memory communicatively coupled to the at least one processor; at least one network interface 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 configured to receive, from the customer device, customer identity data and a request to restore a customer wallet; the at least one processor is configured to verify the identity data of the customer received from the customer device; when the at least one processor verifies the identity data of the customer received from the customer device, the at least one network interface is configured to communicate a request for a first key associated with the customer wallet to the trusted third party key repository; 23. The computing system of claim 22, wherein 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.

2. 2. The computing system of claim 1, wherein, when the at least one network interface receives the first key associated with the customer wallet from the key repository of the trusted third party, 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 at least one processor 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; transferring digital assets from the old customer wallet to the new transaction address using the first key and the second key; 3. The computing system of claim 2, configured to restore the customer wallet using, at least in part, the first key associated with the customer wallet and the second key associated with the customer wallet.

4. the customer wallet comprises a plurality of old transaction addresses, each of which is associated with three private keys; 4. The computing system of claim 3, wherein each old transaction address requires at least two of the three private keys associated with the respective old transaction address to access the digital assets of the respective old transaction address.

5. The at least one network interface is 4. The computing system of 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 configured to communicate the one or more new private keys to the customer device. The computing system of claim 5 .

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

8. The at least one processor by comparing said identity data with previously stored identity data of said customer; The computing system of claim 1 , configured to, at least in part, verify the identity data of the customer received from the customer device.

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

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

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

12. a computing device configured to communicate with a trusted third party and a customer device of the customer; a key repository communicatively coupled to the computing device; the computing device is configured to receive, from the customer device, customer identity data and a request to restore a customer wallet; the computing device is configured to verify the identity data of the customer received from the customer device; the computing device is configured to communicate a request for a first key associated with the customer wallet to the trusted third party key repository; 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.

13. 13. The system of claim 12, wherein, upon receiving the first key associated with the customer wallet from the key repository of the trusted third party, 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 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; transferring digital assets from the old customer wallet to the new transaction address using the first key and the second key; 14. The system of claim 13, configured to restore the customer wallet using, at least in part, the first key associated with the customer wallet and the second key associated with the customer wallet.

15. the customer wallet comprises a plurality of old transaction addresses, each of which is associated with three private keys; 15. The system of claim 14, wherein each old transaction address requires at least two of the three respective private keys associated with the respective old transaction address in order to access the digital assets of the respective old transaction address.

16. The computing device further comprises:

15. The system of claim 14, configured to communicate the new transaction address associated with the new customer wallet to the customer device.

17. The computing device further comprises: The system of claim 16 , configured to communicate the one or more new private keys to the customer device.

18. 20. The system of claim 17, wherein the new private key is a private transaction key.

19. The computing device comprises: by comparing said identity data with previously stored identity data of said customer; The system of claim 12 , configured to, at least in part, verify the identity data of the customer received from the customer device.

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

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

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

23. receiving, at a computing device, from a customer device, customer identity data and a request to restore the customer wallet; verifying, at the computing device, the identity data of the customer received from the customer device; communicating a request for a first key associated with the customer wallet to a trusted third party key repository upon validation of the customer identity data received from the customer device; receiving the first key associated with the customer wallet from the key repository of the trusted third party; The customer wallet can be restored using the first key associated with the customer wallet and a second key associated with the customer wallet.

24. 24. The computerized method of claim 23, further comprising: restoring the customer wallet at 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 second key stored in said second storage device, said step of restoring said customer wallet on said computing device comprising: 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 an old customer wallet to the new transaction address using the first key and the second key.

26. the customer wallet comprises a plurality of old transaction addresses, each of which is associated with three private keys; 26. The computerized method of claim 25, wherein each old transaction address requires at least two of the three respective private keys associated with the respective old transaction address in order to access the digital assets of the respective old transaction address.

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

28. 26. The computerized method of claim 25, further comprising the step of communicating the new private key or keys to the customer device.

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

30. Validating, at the computing device, the identity data of the customer received from the customer device, comprises:

24. The computerized method of claim 23, comprising the step of comparing the identity data with previously stored identity data for the customer.

31. 24. The computerized method of claim 23, wherein the identity data comprises biometric data.

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

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

Images