Method and system for managing cryptocurrency

Abstract

The present disclosure generally relates to a method, system, apparatus, and non-transitory computer-readable medium for managing cryptocurrency. The cryptocurrency management system includes a cryptocurrency management device (CMD), a mobile communication device (MCD), and a cryptocurrency management server (CMS), each configured to store a respective private key for use in generating a respective authentication signature for a multi-signature address in a cryptocurrency network. Any two of three authentication signatures that can be generated by the CMD, MCD, and CMS can be combined to generate a fully authenticated request to transfer cryptocurrency associated with the multi-signature address. The system provides users with a flexible self-management solution that allows them to transfer cryptocurrency without needing to access the private key stored in the CMS. However, the CMS allows for recovery in the event of loss or unavailability of one or both of the CMD and / or MCD.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Utility Patent Application No. 18 / 223,486, filed July 18, 2023, which claims priority to U.S. Provisional Patent Application No. 63 / 396,208, filed August 8, 2022, both of which are incorporated herein by reference in their entireties.

[0002] (Technical field) Cryptocurrencies such as Bitcoin are growing in popularity and offer many advantages. In this regard, cryptocurrencies provide a digital form of currency that can be transferred from one party to another over a global computer network, such as the Internet, thereby facilitating the storage and transfer of financial assets for financial transactions. This digital nature allows cryptocurrencies to offer numerous benefits not possible with more traditional currencies. However, the digital nature of cryptocurrencies also poses unique challenges. For example, using cryptographic keys to access and control cryptocurrency assets can involve users maintaining and memorizing these keys. This can increase complexity for users and potentially increase the likelihood that a user will lose access to their cryptocurrency assets by losing their memorized cryptographic keys. Additionally, memorizing these cryptographic keys can also increase the likelihood that a malicious actor will gain access to a user's memorized cryptographic keys and subsequently steal the user's cryptocurrency assets.

[0003] In particular, cryptocurrency users often face a choice between third-party custody and self-custody. Third-party custody relies on a third party to hold information, such as private keys, used by owners to establish ownership and transfer cryptocurrency. Such a solution may be attractive to users who do not want to bear many of the complexities of storing, processing, and transferring information related to cryptocurrency. However, many users may have concerns about the security measures used by third-party custodians to keep cryptocurrency safe and about retaining their ability to access cryptocurrency from third-party custodians, such as during bankruptcy or other unforeseen events similar to the loss of credentials required by the third-party custodian. With self-custody, owners must overcome the technical complexities associated with managing cryptocurrency and also address security concerns. Many users may also be concerned about their ability to access cryptocurrency in the event of loss or damage to the hardware used to store and otherwise manage cryptocurrency. [Brief explanation of the drawings]

[0004] The present disclosure can be better understood with reference to the following drawings. The elements of the drawings are not necessarily to scale relative to each other, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, like reference characters indicate corresponding parts throughout the several views.

[0005] [Figure 1] FIG. 1 is a block diagram of an exemplary cryptocurrency management system.

[0006] [Figure 2] FIG. 2 is a flowchart of an exemplary method for using social restoration.

[0007] [Figure 3A] FIG. 3A is an illustration of a graphic user interface (GUI) for using social recovery. [Figure 3B]FIG. 3B is an illustration of a graphic user interface (GUI) for using social recovery.

[0008] [Figure 4] FIG. 4 is a block diagram of the cryptocurrency management device (CMD) shown in FIG.

[0009] [Figure 5] FIG. 5 is a block diagram of a mobile communication device (MCD) such as that shown in FIG.

[0010] [Figure 6] FIG. 6 is a block diagram of a cryptocurrency management server (CMS) such as that shown in FIG.

[0011] [Figure 7] FIG. 7 illustrates front and rear views of an exemplary mobile communication device such as that shown in FIG.

[0012] [Figure 8] FIG. 8 is a flowchart of an exemplary method for using delay and notification. DETAILED DESCRIPTION OF THE INVENTION

[0013] The present disclosure generally relates to systems and methods for managing and using digital financial assets, such as cryptocurrencies. In some embodiments of the present disclosure, a cryptocurrency management system includes a cryptocurrency management device (CMD), a mobile communication device (MCD), and a cryptocurrency management server (CMS), each configured to store a respective private key for use in generating a respective authentication signature for a multi-signature address in a cryptocurrency network. Any two of three authentication signatures that can be generated by the CMD, MCD, and CMS can be combined to generate a fully authenticated request to transfer cryptocurrency associated with the multi-signature address. The system provides users with a flexible self-custody solution that allows them to transfer cryptocurrency without needing to access the private key stored in the CMS. Additionally, the CMS enables recovery in the event of loss or unavailability of one or both of the CMD and / or MCD.

[0014] In some embodiments of the present disclosure, the MCD generally hosts applications that control the management of cryptocurrencies. Certain data used by the applications (such as various private keys) is backed up by storing encrypted copies of the data on a cloud server, and copies of the keys are used to encrypt the backup data provided to the CMS. If the original MCD or applications are lost, the encrypted backup data can be downloaded to a new MCD (or the original MCD, if available) and used to recover the private keys stored in the original MCD. Specifically, to recover the private keys stored in the original MCD, the MCD may encrypt the backup and communicate with the CMS to obtain a key used to decrypt the backup using the obtained encryption key. In some embodiments, users may be authenticated for key recovery or cryptocurrency transactions by providing biometric input to the MCD or otherwise, without the need to provide a password, PIN, or other information to be memorized, thereby increasing the flexibility of the system.

[0015] During recovery of a lost private key, the system may be configured to delay the completion of financial transactions and provide notification of pending financial transactions so that authorized users can be notified of any transactions that are deemed fraudulent and then reversed. In some embodiments, the system also enforces at least some constraints, such as spending limits, during the recovery process once the system is notified of the lost key, thereby limiting the amount of funds that can be transferred by a fraudulent user potentially exploiting a vulnerability in the recovery process.

[0016] In some embodiments, a registering authorized user is permitted to list social recovery contacts that can be used for authentication in recovering a lost key. In this regard, when a key is lost, the system provides a code that the authorized user can communicate to the social recovery contacts. The system also communicates with the social recovery contacts and prompts them to provide the code. If at least a minimum number of the social recovery contacts provide a valid code, the system authenticates the user during the recovery process and allows recovery of one or more lost keys. Thus, authorized users can be authenticated without having to provide a password, PIN, or other information that must be memorized by the user, thereby facilitating recovery.

[0017] Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings, in which like numbers in different drawings represent the same or similar elements, unless otherwise indicated. The implementations set forth in the following description of exemplary embodiments do not represent all implementations consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with aspects related to the present invention as set forth in the appended claims. Certain aspects of the present disclosure are described in more detail below. The terms and definitions provided herein control in the event of a conflict with terms and / or definitions incorporated by reference.

[0018] One potential barrier to more mainstream adoption of self-custody solutions is the need to create and physically protect visually sensitive backup materials to maintain their security. This means moving away from a reliance on long (e.g., 12- or 24-word) seed phrases that users record on media like paper or metal (to be secure). Such solutions leave malicious users with even brief access to this material potentially using it to steal or otherwise misappropriate cryptocurrency. Seed phrases have worked well for many experienced users. However, they can create an intimidating experience for new cryptocurrency users and provide a relatively easy opportunity for bad actors to exploit customers who do not fully understand their importance, such as by persuading customers to share their seed phrases over the phone, tricking customers into entering a previously compromised seed phrase during wallet setup, or compromising a customer's cloud storage account, including a photo of the physical paper seed phrase card that accompanies the wallet. Additionally, many users create secrets, like passwords, that are sometimes easy to remember but can also be vulnerable to hackers, and in some cases users may create secrets that are more secure but difficult to remember. Techniques for providing robust security for assets such as cryptocurrencies without requiring users to remember complex secrets (e.g., passwords) are generally desirable.

[0019] To this end, it is generally desirable to enable recovery of lost private keys without requiring the user to maintain backup materials and without requiring the user to cede control of their cryptocurrency account to a third party.

[0020] FIG. 1 is a simplified block diagram of a cryptocurrency management system. As shown, cryptocurrency management system 102 may include a cryptocurrency management device (CMD) 103, a cryptocurrency management server (CMS) 105, and a mobile communication device (MCD) 104. Also shown in FIG. 1 is a cryptocurrency network 106 and a cryptocurrency address 107 associated with one or more transactions within cryptocurrency network 106. Generally, MCD 104 may interact with CMD 103 and CMS 105 to, among other things, generate and submit valid cryptocurrency transactions. As part of this process, CMS 105 and MCD 104 may also interact with cryptocurrency network 106.

[0021] Generally, each of devices 103, 104, and 105 may also include cryptocurrency account private keys (i.e., private keys 108, 110, and 115) and control logic (i.e., control logic 109, 112, 114, and 119). As described further below, each private key 108, 110, and 115 is a cryptographic key associated with the private key of a public-private key pair (in the case of a multi-signature address, one private key of the public-private key pair) of a cryptocurrency address (e.g., cryptocurrency address 107). Also, as described further below, control logic 109, 112, 114, and 119 may include instructions that may be executed by a respective processor or set of processors of that device to perform various functions of that device.

[0022] The private key 110 can be associated with a cryptocurrency management application (app) 113 executed by the MCD 104 for purposes of generally managing the cryptocurrency addresses 107. To this end, the cryptocurrency management app 113 can be associated with user account information 111 used to authenticate the MCD 104 to the CMS 105 and generally enable the cryptocurrency management app 113 to interact with the MCD 105. The cryptocurrency management app can also be associated with app control logic 112, which includes instructions that can be executed by a processor or set of processors of the MCD 104 to perform the functions of the cryptocurrency management app 113. Note that in some embodiments of the present disclosure, functions described herein as being performed by the app control logic 112 can also be performed by the device control logic 114, and vice versa. In some embodiments, the app control logic 112 and the device control logic 114 are combined into a single control logic that can be used to orchestrate the operation of the MCD 104 and manage cryptocurrency in accordance with the techniques described herein.

[0023] The MCD 104 may also be associated with a cloud server 115 that the MCD 104 can use to store certain data off-device, such as for storing data backups. As part of this, the cryptocurrency management app 113 may encrypt a copy of the private key 110 and store the encrypted copy on the cloud server 115 as an MCD private key encrypted backup 116. The MCD 104 may provide the CMS 105 with a copy of the encryption key used to encrypt the backup 116, referred to as an MCD backup encryption key 117. The CMS 105 may associate and store the MCD backup encryption key 117 on non-volatile memory accessible by the CMS 105. Note that the cryptocurrency management app 113 may also store other data on the cloud server 115. Note that the cryptocurrency management app 113 may also maintain a local copy of the MCD backup encryption key 117 in some embodiments.

[0024] Additionally, the private key 115 may be associated with a user account 118. The user account 118 may be managed as part of an online platform maintained by a third-party custodian using an online platform that includes the CMS 105. As described in more detail below, the user account 118 may be associated with additional information, including a cryptocurrency address 107, information about the user (also known as the owner) of the user account 118, an MCD backup encryption key 117, and various configuration options such as security policies 116.

[0025] At a high level, the cryptocurrency management system 102 acts to manage the cryptocurrency addresses 107 by controlling the use of cryptocurrency funds associated with the cryptocurrency addresses 107 in transactions. In this regard, the cryptocurrency management system 102 can be thought of as an association of devices or systems that (1) are each distributed a portion of the authority to control the cryptocurrency addresses 107 and (2) are configured to cooperate with each other to use their collective authority to control the cryptocurrency addresses 107 (e.g., generate and submit associated transactions). In other words, the ability to manage the cryptocurrency addresses 107 is divided among the CMD 103, the MCD 104, and the CMS 105. In some embodiments, the CMD 103, the MCD 104, and the CMS 105 communicate with each other to agree on the transaction before signatures for the transaction are obtained and the authenticated transaction is generated and submitted to the cryptocurrency network 106.

[0026] In some embodiments, the cryptocurrency address 107 is a multi-signature address in which a private key is used as an authentication key distributed across the CMD 103, MCD 104, or CMS 105. As an example, there may be three private keys associated with the cryptocurrency address 107, and each of the CMD 103, MCD 104, and CMS 105 may store a respective one of them, and each of the CMD 103, MCD 104, and CMS 105 may only allow access to that private key if the user can provide acceptable authentication credentials. Furthermore, the cryptocurrency address 107 may be configured to be able to generate fully authenticated cryptocurrency transaction requests for cryptocurrency assets associated with the cryptocurrency address 107 using any two of the private keys. In other embodiments, other numbers of private keys may be used to generate fully authenticated cryptocurrency transaction requests.

[0027] In some embodiments, the owner of the cryptocurrency assets associated with address 107 may maintain physical possession of CMD 103 and MCD 104, and CMS 105 is maintained by a trusted third party. Additionally, the owner may keep CMD 103 in a secure location, such as their home. Thus, if MCD 104 is stolen, a fraudulent user should not be able to use MCD 104 to generate fully authenticated cryptocurrency transactions involving cryptocurrency assets associated with cryptocurrency address 107 because the fraudulent user (1) would not have physical access to or be able to communicate with CMD 103 (which, as described above, may be designed to allow only short-range communication) and (2) would not be able to access the private key stored in CMS 105 without providing valid authentication credentials to CMS 105.

[0028] Additionally, when the owner desires to initiate a transaction, the owner can transfer the MCD104 to the CMD103 or to the CMD104 so that the CMD103 and the MCD104 can communicate to generate a fully authenticated cryptocurrency transaction. In this regard, after providing the CMD103 with a valid authentication certificate, the CMD103 can use the private key stored therein to generate an authentication signature that is communicated to the CMD103, which can then use the private key stored therein to generate an authentication signature that can be combined with the authentication signature from the CMD103 to generate a fully authenticated request for the cryptocurrency transaction. The CMD103 can then transmit such a request to the cryptocurrency network 106. Thus, devices in the owner's physical possession (i.e., the CMD103 and the MCD104) can be used to generate fully authenticated cryptocurrency transactions without using the CMS 105, thereby giving the owner complete control over their cryptocurrency transactions if the CMS 105 becomes unavailable for any reason. However, the CMS 105 remains available for recovery if the CMD 103 and / or MCD 104 are lost, stolen, fail, or are unavailable.

[0029] Specifically, if the original MCD 104 is lost or otherwise becomes unavailable, the original MCD 104 can be replaced with a new MCD 104 that can communicate with the CMD 103 and the CMS 105 to obtain two authentication signatures that can be combined to form a fully authenticated cryptocurrency transaction. Also, if the CMD 103 is lost or otherwise becomes unavailable, the MCD 104 can communicate with the CMS 105 (as described above for the CMD 103) to obtain an authentication signature that can then be combined with the authentication signature from the MCD 104 to generate a fully authenticated cryptocurrency transaction. Thus, the embodiment shown by FIG. 1 and described above provides flexibility to the owner while maintaining security and also allows for recovery if any of the CMD 103, MCD 104, or CMS 105 is lost.

[0030] Additionally, the cryptocurrency management system 102 may also enable lost key recovery. Specifically, in some embodiments, the CMS 105 may be used to recover a lost private key 110, such as may occur through the loss or failure of the MCD 104. For example, in an exemplary embodiment, if a user loses access to their private key 110, the user may retrieve an MCD private key encryption backup 116 from the cloud server 115 and an MCD backup encryption key 117 from the CMS 105 to recover the lost private key 110. As part of this key recovery process, the CMS 105 may require the user initiating the key recovery process to prove their identity as the owner of the user account 118.

[0031] In some embodiments, CMS 105 may require a user to prove their identity as the owner of cryptocurrency address 107 through a process hereinafter referred to as “social recovery,” in which information from a specified trusted party is used. In this regard, when a user is setting up a user account 118, the user may provide contact information (e.g., a phone number, email address, a user handle with a service provider, or a similar identifier) of at least one social recovery contact that can be used to assist in recovering or authenticating the recovery of a lost key. The user may then utilize the user account 118 to communicate with CMS 105 and initiate the recovery process, such as through an application on MCD 104 or through an online web portal of an associated online platform. In response, CMS 105 may be configured to provide a respective set of social recovery credentials to one or more of the user's social recovery contacts. The user of user account 118 may request the set of credentials sent by the social recovery contact and be instructed to provide the set of credentials to CMS 105. The social recovery contact may be instructed to provide the set of credentials sent to the user of user account 118.

[0032] After the user of user account 118 retrieves a (sufficient) set of social recovery credentials, the user can provide the retrieved set of social recovery credentials to CMS 105. The set of social recovery credentials can be provided to CMS 105 as part of a social recovery verification message, which can include additional information from the user, such as a (sufficient) password associated with user account 118. When the user provides a (sufficient) correct set of social recovery credentials, possibly along with other required information (e.g., a (hashed) derived from the) password associated with user account 118, CMS 105 can provide MCD backup encryption key 117 to the user, such as by sending MCD backup encryption key 117 directly to MCD 104.

[0033] Alternatively, in some embodiments, the process may be reversed by the user of the user account 118 receiving one or more sets of social recovery credentials associated with the social recovery contacts of the user account 118. The user may provide these codes to each of the respective social recovery contacts and instruct the contacts to enter the codes into an online website associated with the online web portal of the associated online platform. In parallel, the social recovery contacts may be provided with a message indicating that a key recovery process has been initiated for the user account 118 and a link to a website where the social recovery contact can enter the set of social recovery credentials they receive from the owner of the user account 118. Naturally, the social recovery contact's willingness to comply with entering the set of social recovery credentials into the website depends largely on the contact's assessment of whether the owner of the user account 118 initiated the process, as opposed to a malicious third party. Once a sufficient number of social recovery contacts have entered the set of social recovery credentials received from the owner of the user account 118, the CMS 105 may provide the MCD backup encryption key 117 to the user, such as by sending the MCD backup encryption key 117 directly to the MCD 104.

[0034] In some other embodiments, CMS 105 may provide the social recovery contact with a message indicating that a key recovery process has been initiated for user account 118, and instead of entering the set of social recovery credentials received from the owner of user account 118, may provide a link to a website where the contact can instead submit, in any manner they prefer, that they have verified that the owner of user account 118 has initiated the process.

[0035] In yet other embodiments, the owner of the user account 118 may indicate a social recovery contact, and before a key recovery process is initiated for the user account 118, the CMS 105 may provide the social recovery contact with a message indicating that the contact has been identified as a social recovery contact by the owner of the user account 118 and requesting that the contact install an application on their mobile device to assist in the subsequent key recovery process. The CMS 105 may then use the application installed on the social recovery contact's mobile device to authenticate that the owner of the user account 118 has initiated the process. In some embodiments, the installed application may be partially installed or temporarily installed. For example, the installed application may provide application data for storage on a cloud backup, the mobile device may then uninstall the application, and when the social recovery contact is prompted to participate in the social recovery process, the social recovery contact may reinstall the application, which may then automatically retrieve the previously stored application data from the cloud backup. In other embodiments, instead of an installed application, the social recovery contact may be asked to download and run an application that performs the functions of the installed application without installing the application.

[0036] 2 is a flowchart illustrating a process for recovering a lost private key using social recovery. For example, the process may be used after a user reinstalls (and reconfigures) the cryptocurrency management app 113 on an original MCD 104, or after installing (and configuring) the cryptocurrency management app 113 on a new MCD 104 (e.g., after the original MCD 104 is lost and replaced with a new MCD 104). In some embodiments, this process may be used specifically when access to the private key 110 is lost while access to the CMD 103 is also lost.

[0037] Initially, as indicated by block 202 of FIG. 2 , a user account owner may interact with the CMS to submit a key recovery request. In some embodiments, this may involve the user logging into the user account 118 via the cryptocurrency management app 113, which then transmits the key recovery request from the MCD 104 to the CMS 105. Alternatively, in some embodiments, the user may log into the user account 118 through an online web portal associated with the CMS 105 and transmit the key recovery request to the CMS 105 through this web portal. In some embodiments, before the CMS 105 acts on the recovery request, the user may be required to provide authentication information indicating the request is from the owner of the user account 118. For example, in some embodiments, the CMS 105 may require the user to provide login credentials (e.g., username and password) used to access the user account 118. As another example, the CMS 105 may require the user to use one of the private keys associated with the cryptocurrency address 107, such as private key 108, to generate a valid signature of a hash of data provided to the user by the CMS 105. The CMS 105 can then use the corresponding public key to verify the authenticity of the signature and also verify that the signature is for the hash sent to the user by hashing the data provided to the user.

[0038] After a key recovery request is submitted, the CMS receives the request and may initiate and begin recovery procedures in accordance with the security policy of the user account for the cryptocurrency address. More precisely, as indicated by block 203 of FIG. 2 , the CMS may receive the key recovery request and, using the social recovery contact information indicated by the security policy of the user account, send a set of social recovery credentials to each of one or more social recovery contacts. In general, security policies indicate specific configuration options that control the CMS's response to certain actions and the requirements the CMS imposes before performing those actions. For example, in some embodiments, the CMS 105 may attempt to participate in the authentication of a cryptocurrency transaction requested by a user logged into the user account 118 if the requested transaction is less than a certain value. This value may be configured as part of a subset of security policies known as transaction policies. As another example, the security policies 116 may indicate whether the CMS 105 will participate in a key recovery operation (i.e., whether it is willing to act on a key recovery request) and the requirements the CMS 105 imposes before doing so. If the CMS 105 requires social recovery, the security policy 116 may also list contact information for one or more social recovery contacts.

[0039] For example, CMS 105 may determine that security policy 116 for the user indicates that social recovery contact 121, social recovery contact 122, and social recovery contact 123 are social recovery contacts for user account 118, and based on that determination, sends a set of social recovery credentials to social recovery contacts 121, 122, and 123 using social recovery contact information 124 indicated by security policy 116. Specifically, CMS may send the set of social recovery credentials to the social recovery contacts using the social recovery contact information indicated by the security policy for the social recovery contacts. Similarly, CMS may send the set of social recovery credentials to the social recovery contacts using the social recovery contact information indicated by the security policy for the social recovery contacts, and may send the set of social recovery credentials to the social recovery contacts using the social recovery contact information indicated by the security policy for the social recovery contacts.

[0040] In some embodiments, the set of social recovery credentials may comprise a numeric code. For example, in some embodiments, the set of social recovery credentials sent to the social recovery contact 123 may comprise a six-digit number. In other embodiments, a different number of digits may be utilized, such as eight digits, eleven digits, etc. In some embodiments, the transmitted set of social recovery credentials may comprise an alphanumeric passcode. For example, in some embodiments, the set of social recovery credentials sent to the social recovery contact 123 may include a six-character alphanumeric sequence. In other embodiments, a different number of characters may be utilized, such as an eight-character word, a nine-character word, etc.

[0041] After the set of social recovery credentials is sent to the social recovery contacts through their respective social recovery contact information, each of the social recovery contacts can receive or otherwise obtain access to their respective set of social recovery credentials, as indicated by block 204 of FIG. 2. For example, for a social recovery contact whose contact information is a phone number, the social recovery contact can receive the set of social recovery credentials via a smartphone device associated with the phone number. As another example, for a social recovery contact whose contact information is an email address, the social recovery contact can receive the set of social recovery credentials via an email received by a device (e.g., a smartphone, tablet, personal computer (PC), etc.) that has access to an inbox associated with the email address.

[0042] 2, after the sets of social recovery credentials are received by the social recovery contacts, the social recovery contacts can provide their respective sets of social recovery credentials to the owners of the user accounts. This may involve, for example, each social recovery contact communicating with the owner of user account 114 to verify that the owner of user account 118 has initiated or otherwise authorized the key recovery request.

[0043] As indicated by block 206 of FIG. 2 , after the social recovery contacts send their respective sets of social recovery credentials to the user account owner, the user account owner can receive the set of social recovery credentials. The user account owner can then send the received set of social recovery credentials to the CMS. For example, in some embodiments, the owner of the user account 118 can log in to the user account 118 via the cryptocurrency management app 113. The cryptocurrency management app 113 can then provide the user with an interface for entering a social recovery verification code. After the user enters the social recovery verification code, the cryptocurrency management app 113 can transmit the entered social recovery verification code from the MCD 104 to the CMS 105. Alternatively, in some embodiments, the owner of the user account 118 can log in to the user account 118 through an online web portal associated with the CMS 105. The online web portal can then provide the user with an interface for entering the social recovery verification code. After the user enters the social recovery verification code, the associated online web portal can transmit the entered social recovery verification code to the CMS 105 from the device on which the online web portal is running. Generally, the social recovery verification code may be sent to the MCD as part of a social recovery verification message.

[0044] 3A-3B are diagrams of a graphic user interface (GUI) for using social recovery. As shown, an account owner can initiate the process of authenticating a backup key recovery request using social recovery. In particular, as shown in FIG. 3A, the account owner can trigger CMS 105 to send social recovery credentials to a social recovery contact specified in the account's security policy. Here, the social recovery credentials are represented by a four-digit numeric code. As shown in FIG. 3B, the account owner can then receive the numeric code from the social recovery contact, such as by having the social recovery contact verbally communicate the code via a video call, and enter the received numeric code to complete the social recovery authentication process.

[0045] 2, after the owner of the user account 114 transmits the social recovery verification codes to the CMS 105, the CMS 105 may receive and verify the transmitted social recovery verification codes. If a sufficient number of the social recovery verification codes provided by the owner of the user account 114 match the social recovery verification codes transmitted by the CMS 105 to the social recovery verification contact 120, the CMS 105 may transmit the MCD backup encryption key 117 to the owner of the user account 114.

[0046] As indicated by block 208 of FIG. 2 , at some point before, during, or after, possibly any of the steps shown in blocks 202-207 of FIG. 2 , MCD 104 may retrieve MCD private key encrypted backup 116 from cloud server 115.

[0047] As indicated by block 209 in FIG. 2 , after MCD 104 retrieves MCD private key encrypted backup 116 and obtains MCD backup encryption key 117 sent by CMS 105, MCD 104 can recover private key 110 by decrypting MCD private key encrypted backup 116 using MCD backup encryption key 117.

[0048] 4 is a block diagram of a cryptocurrency management device (CMD), such as CMD 103 of FIG. 1. As shown by the diagram, CMD 103 may include at least one processor 403 connected to a communication interface 404 and memory 405. CMD 103 may be a standalone mobile device or other types of devices, such as desktop devices not designed for mobility. In general, processor 403 may interact with and control other components of CMD 103, as well as other components, to coordinate device functionality. Communication interface 404 may include circuitry configured to communicate with other devices via various communication channels.

[0049] For example, in some embodiments, communication interface 404 may enable communication only over short-range peer-to-peer communication channels (e.g., Bluetooth, Near Field Communication (NFC), or Radio Frequency Identification (RFID)). Alternatively, in some embodiments, communication interface 404 may use a network such as the Internet. By way of example, communication interface 404 may comprise a modem, a wireless radio (e.g., a cellular transceiver), or other device designed to communicate wirelessly with other devices or with a network access point, such as a cellular tower, a network router, a Wi-Fi hotspot, or other type of access point. Generally, as relevant herein, communication interface 404 may be used to communicate with components of cryptocurrency management system 102, such as CMS 105 and MCD 104, as well as with (particular nodes of) cryptocurrency network 106.

[0050] It should be noted that in some embodiments, CMD103 is intentionally designed to only allow short-range communication, such as NFC or Bluetooth, so that CMD103 cannot be accessed remotely using a network, thereby enhancing the security of CMD103 and the data stored thereon.

[0051] The memory 405 is coupled to and editable by the processor 403. The memory 405 may store, among other things, a cryptocurrency account private key 108 and device control logic 109. As described further below, the private key 108 is a cryptographic key associated with the private key of a public-private key pair (or, in the case of a multi-signature address, one private key of the public-private key pair) of a cryptocurrency address (e.g., cryptocurrency address 107). As described further below, the device control logic 109 may include instructions that may be executed by the processor 403 to perform various functions of the CMD 103 described herein, including initiating or processing transactions involving the cryptocurrency address 107.

[0052] In operation, the processor 403 may execute instructions of the device control logic 109 to manage cryptocurrency assets associated with the cryptocurrency address 107. This may involve communicating with the CMS 105 and the MCD 104 to obtain (or generate) authentication signatures, as well as communicating with (nodes of) the cryptocurrency network 106. To obtain signatures from the CMS 105 or the MCD 104, the processor 403 may interact with the communication interface 404 to communicate with the CMS 105 and the MCD 104.

[0053] It should be noted that the device control logic 109 may be implemented in software, hardware, firmware, or any combination thereof. In the exemplary CMD 103 shown in FIG. 4, the device control logic 109 is implemented in software and stored in memory 405. When implemented in software, the device control logic 109 may be stored on and transmitted over any computer-readable medium for use by or in connection with an instruction execution device capable of fetching and executing instructions, such as the processor 403. In the context of this specification, a "computer-readable medium" may be any means capable of containing or storing a computer program for use by or in connection with an instruction execution device.

[0054] In some embodiments, the CMD 103 may have a biometric (living) sensor 408 for authenticating an authorized user. For example, in some embodiments, the biometric sensor 408 is a fingerprint sensor located on the surface of the CMD 103, although other examples allow other types of biometric sensor 408. Other embodiments may not have a biometric sensor.

[0055] Note that in some embodiments, CMD103 may not need access to the Internet or some other form of wireless network. Rather, in some embodiments, CMD103 may communicate only through short-range communication channels, requiring any device, such as MCD104, that attempts to interact with CMD103 to be physically close to CMD103 (e.g., within a few feet). Limiting the range of CMD103 helps improve security by preventing at least some attempts by unauthorized users to access data stored on CMD103. In fact, CMD103 can be kept in a secure location inaccessible to many hackers for long periods of time. When communication with CMD103 is desired, such as for approval of a transaction involving a cryptocurrency managed by CMD103, MCD104 may be sent to CMD103.

[0056] In some embodiments, the CMD 103 may have a small, tag-like form factor that, among other things, allows the CMD 103 to be easily carried (portable). When the CMD 103 is portable, it may be moved to a location associated with the transaction, i.e., the location of sale of the product or service purchased with the cryptocurrency, such that the MCD 104 does not need to be moved to a secure location where the CMD 103 is typically kept (e.g., the user's home). In other embodiments, the CMD 103 may have a larger, less portable form factor.

[0057] Figure 5 is a block diagram of a mobile communication device (MCD), such as MCD 104 of Figure 1. MCD 104 may be implemented as a smartphone, although other types of MCDs 105 are possible, such as a laptop or other type of handheld.

[0058] As shown by the figure, MCD 104 may include at least one processor 503 connected to a network interface 504 and memory 505. Generally, processor 503 may interact with and control other components of MCD 104 to coordinate device functionality. Network interface 504 may include circuitry configured to communicate with other devices over various networks, such as the Internet. By way of example, network interface 504 may include a modem, a wireless radio (e.g., a cellular transceiver), or other device designed to communicate with a network access point, such as a cellular tower, a network router, a Wi-Fi hotspot, or other type of access point.

[0059] Through these access points, the MCD 104 may communicate with various networks, such as a cellular network, a Wi-Fi network, the Internet, or other networks or combinations of networks. Through these various networks, the MCD 104 can communicate with components of the cryptocurrency management system 102, such as the CMD 103 and the CMS 105, as well as with the cryptocurrency network 106 (at a particular node). Any of the components of the cryptocurrency management system 102, including the MCD 104, may include other types of interfaces, such as a near-field communication interface. The MCD 104 may also include other types of interfaces. For example, in some embodiments, the MCD 104 may include a near-field communication interface, such as a near-field communication (NFC) or Bluetooth transceiver, to enable wireless communication with other devices proximate to the MCD 104.

[0060] The memory 505 is coupled to and editable by the processor 503. The memory 505 may store, among other things, a cryptocurrency account private key 110 and device control logic 114. As described further below, the private key 110 is a cryptographic key associated with the private key of a public-private key pair (e.g., one private key of the public-private key pair, in the case of a multi-signature address) of a cryptocurrency address (e.g., cryptocurrency address 107). As described further below, the device control logic 114 may include instructions that may be executed by the processor 503 to perform various functions of the MCD 104 described herein, including initiating or processing transactions involving the cryptocurrency address 107.

[0061] In operation, the processor 503 may execute instructions of the device control logic 114 to manage cryptocurrency assets associated with the cryptocurrency address 107. This may involve communicating with the CMD 103 and the CMS 105 to obtain (or generate) authentication signatures, as well as communicating with (nodes of) the cryptocurrency network 106. To obtain signatures from the CMD 103 or the CMS 105, the processor 503 may interact with the network interface 504 to communicate with the CMD 103 and the CMS 105.

[0062] It should be noted that device control logic 114 may be implemented in software, hardware, firmware, or any combination thereof. In the example MCD 104 illustrated by FIG. 5, device control logic 114 is implemented in software and stored in memory 505. When implemented in software, device control logic 114 may be stored on and transmitted over any computer-readable medium for use by or in connection with an instruction execution device capable of fetching and executing instructions, such as processor 503. Relatedly, in some embodiments, device control logic 114 may be part of a software application running on MCD 104.

[0063] In some embodiments, MCD 104 may also comprise an input device 508 and an output device 509. Generally speaking, output device 503 is configured to communicate information to a user via some mechanism, such as a digital display. Processor 503 may interact with output device 503 to transmit data to the user. Conversely, input device 508 is configured to receive input from a user of MCD 104. For example, input device 508 may be a touchscreen capable of receiving user input in the form of taps, gestures, and other physical interactions with the screen. As illustrated by this example, input device 508 and output device 509 may comprise the same device (e.g., a touchscreen display) in some embodiments. Furthermore, in some embodiments, either or both of input device 508 and output device 509 may comprise two or more physical devices.

[0064] FIG. 6 is a block diagram of a cryptocurrency management server (CMS), such as CMS 105 of FIG. 1. As shown by the diagram, CMS 105 may include at least one processor 603 connected to a network interface 604 and memory 605. Generally, processor 603 may interact with and control other components of CMS 105, as well as other components, to coordinate device functionality. Network interface 604 may include circuitry configured to communicate with other devices over various networks, such as the Internet. By way of example, network interface 604 may include a modem, a wireless radio (e.g., a cellular transceiver), or other device designed to communicate with a network access point, such as a cellular tower, a network router, a Wi-Fi hotspot, or other type of access point. Generally, as relevant herein, network interface 604 may be used to communicate with components of cryptocurrency management system 102, such as CMD 103 and MCD 104, as well as with cryptocurrency network 106 (for a particular node).

[0065] The memory 605 is coupled to and editable by the processor 603. The memory 605 may store, among other things, a cryptocurrency account private key 115 and server control logic 119. As described further below, the private key 115 is a cryptographic key associated with the private key of a public-private key pair (e.g., one private key of the public-private key pair, in the case of a multi-signature address) of a cryptocurrency address (e.g., cryptocurrency address 107). Also, as described further below, the server control logic 119 may include instructions that may be executed by the processor 603 to perform various functions of the CMS 105 described herein, including initiating or processing transactions involving the cryptocurrency address 107.

[0066] In operation, the processor 603 may execute instructions of the server control logic 119 to manage cryptocurrency assets associated with the cryptocurrency address 107. This may involve communicating with the CMD 103 and the MCD 104 to obtain (or generate) authentication signatures, as well as communicating with (nodes of) the cryptocurrency network 106. To obtain signatures from the CMD 103 or the MCD 104, the processor 603 may interact with the network interface 604 to communicate with the CMD 103 and the MCD 104.

[0067] It should be noted that the server control logic 119 may be implemented in software, hardware, firmware, or any combination thereof. In the example CMS 105 shown in Figure 6, the server control logic 119 is implemented in software and stored in memory 605. When implemented in software, the server control logic 119 may be stored on and transmitted over any computer-readable medium for use by or in connection with an instruction execution device capable of fetching and executing instructions, such as the processor 603.

[0068] FIG. 7 is a diagram of an exemplary MCD having the aforementioned digital screen. Specifically, the MCD 702 (also referred to as smartphone 702) of FIG. 7 is implemented as a smartphone with a touchscreen 705 on one side of the device (i.e., device front 703) and a camera 706 on the opposite side (i.e., device back 704). The touchscreen 705 covers most of the device front 703 and implements both the input device 508 and the output device 509 of FIG. 5. The touchscreen 705 can output by displaying images and videos. The touchscreen 705 can also receive user input in the form of taps, gestures, and other physical interactions with the screen. Not shown are a processor and memory within the MCD 702 that function similarly to the processor 503 and memory 505 of FIG. 5.

[0069] During the recovery period, when a user has initiated key recovery with CMS 105 but has not yet completed the process, additional security procedures may be implemented by CMS 105. By way of background, when a key is permanently lost, the remaining two keys may still be used to generate transactions. If desired, various constraints, such as spending limits, may be implemented during the recovery process to allow for the use of a minimum number of funds until the recovery process is complete. If desired, various constraints, such as spending limits, may be implemented during the recovery process to allow for the use of a minimum number of funds until the recovery process is complete.

[0070] For example, in some embodiments, the system 102 is configured to implement what is hereinafter referred to as a “delay and notification process” for transactions undergoing a recovery process. In this regard, when notification of a permanently lost key is received, the system 102 is configured to delay the transaction and provide notification of the transaction during the delay so that an authorized user can take steps to stop or prevent the fraudulent transaction. For example, in the above-described embodiment in which the CMD 103 is permanently lost, an application on the MCD 104 may be configured to allow at least some transactions during the recovery period, e.g., transactions within a predetermined spending limit. However, once a transaction is requested, the MCD 104 is configured to delay sending a fully authenticated request to the cryptocurrency network 106 for at least a predetermined time to allow an authorized user to cancel the transaction before the request is sent to the network 106.

[0071] In some embodiments, the CMS 105 may require multiple social recovery contacts to provide valid codes rather than a single social recovery contact to provide additional security. Additionally, some embodiments may use the delay and notification process described above until the recovery process is complete. This may be used to allow an authorized user to reverse any fraudulent transactions that may be attempted during the recovery process. Thus, rather than relying on a password and PIN for recovery, the system 102 allows an authorized user to use a social recovery contact to help authenticate the user for key recovery, although the system 102 may also use a password and PIN, if desired.

[0072] Note that the system 102 may allow an authorized user to list multiple social recovery contacts and may allow recovery if the minimum number of social recovery contacts provide a valid code, if the minimum number of social recovery contacts is less than the total number of social recovery contacts. As an example, a user may define x social recovery contacts, and the CMS 105 may provide the stored key for recovery if any of at least y social recovery contacts provide a valid code, where y is less than x. Thus, recovery may be allowed even if fewer than all of the social recovery contacts are available for verification.

[0073] Additionally, the application on the MCD 104 may be configured to send one or more notifications of the transaction request to a trusted address, such as a phone number or email address, established by the authorized user during registration or updated by the authorized user. Such notifications may include details of the requested transaction, information about steps the user can take to cancel the transaction, and the amount of time remaining in the delay window before the transaction is submitted to the cryptocurrency network 106. Thus, if a fraudulent transaction is requested, the authorized user should receive notification of the fraudulent request and information about steps the user can take to cancel the request before it is submitted to the cryptocurrency network 106. If the delay window expires without the authorized user taking such steps to cancel the request, the application on the MCD 104 may be configured to submit the transaction request to the cryptocurrency network 106. Thus, during recovery processing, the authorized user should be given notification of the requested transaction and given sufficient time to take steps to prevent the fraudulent transaction before it is sent to the cryptocurrency network 106 for processing.

[0074] 8 is a flowchart illustrating a process for recovering a lost private key 108 using delay and notification, as just described. For example, the process may be used after a user activates a new CMD 103 after losing access to the previous CMD 103.

[0075] First, as indicated by block 802 of FIG. 8 , a user account owner can interact with the CMS to send a CMD key exchange request to the CMS. In some embodiments, this may involve the user logging into the user account 118 via the cryptocurrency management app 113, which then sends the CMD key exchange request from the MCD 104 to the CMS 105. Alternatively, in some embodiments, the user can log into the user account 118 through an online web portal associated with the CMS 105 and send the CMD key exchange request to the CMS 105 through this web portal. In some embodiments, before the CMS 105 acts on the CMD key exchange request, the user can be required to provide authentication information indicating a request from the owner of the user account 118. For example, in some embodiments, the CMS 105 can require the user to provide login credentials (e.g., username and password) used to access the user account 118. As another example, CMS 105 may request that a user use one of the private keys associated with cryptocurrency address 107, such as private key 110, to generate a valid signature of a hash of data provided to the user by CMS 105. CMS 105 may then use the corresponding public key to verify the authenticity of the signature and to verify that the signature is for the hash sent to the user by hashing the data provided to the user.

[0076] After the key recovery request is sent, the CMS may receive and then verify the CMD key exchange request, as indicated by block 803 of Figure 8. This may include, for example, the CMS verifying that the CMD key exchange request includes the necessary authentication information.

[0077] After receiving and verifying the CMD key exchange request, the CMS may initiate a CMD key exchange countdown in accordance with the security policy of the user account, as indicated by block 804 of FIG.

[0078] Further, after receiving and verifying the CMD key exchange request, as indicated by block 805 of FIG. 8, the CMS may send a CMD key exchange initiation message to the owner of the account via the contact information for the account owner stored in the security policy.

[0079] After the CMD key exchange countdown expires without being canceled, the CMS, in cooperation with the MCD, authorizes a transaction to transfer funds associated with the cryptocurrency address to a new multi-signature cryptocurrency address protected by the private keys of the CMS, MCD, and the replacement CMD, as indicated by block 806 of Figure 8. For example, in some implementations, the MCD 104 receives the public key of the replacement CMD, generates and signs with its own private key a transaction to transfer funds to the multi-signature cryptocurrency address corresponding to the existing public keys of the CMS 105 and MCD 104 and the new public key of the replacement CMD, which the replacement CMD and CMS 105 then sign with their corresponding private keys, such that only the private key of the replacement CMD is replaced. In another example, CMS105 and MCD104 can each generate a new public / private key pair, CMS105 can send its new public key to MCD104, MCD can receive the replacement CMD's new public key and generate a transaction to transfer funds to a multi-signature cryptocurrency address corresponding to CMS105's new public key, MCD104 signs the replacement CMD, signing it with its own new private key, and then the replacement CMD and CMS105 sign with their corresponding private keys, such that only the replacement CMD's private key is replaced.

[0080] After the funds associated with the cryptocurrency address have been transferred to a new multi-signature cryptocurrency address, as indicated by block 807 of FIG. 8.

[0081] In some implementations, MCD104 and CMD103 can cooperate to generate an authorization token that CMS105 can use to determine whether changes can be made to a user's security policy. MCD104 signs the authorization token with its private key, and CMD103 also signs the authorization token, stores the token, and then sends the authorization token to CMS105 whenever MCD104 is requesting a security policy change based on input from the user. For example, a user can request that a spending limit be increased, and MCD104 can then send a request for the increase along with the authorization token. CMS105 can authenticate that the authorization token is valid based on the public keys of MCD104 and CMD103 before completing the request.

[0082] In some implementations, the authorization token can also be used in the delay and notification process. For example, if a thief steals a user's MCD 104 and attempts to pair the MCD 104 with a different CMD. The CMS 105 can allow the MCD 104 holding the most recently generated authorization token to initiate the delay and notification process once. If the delay and notification process is canceled, or if the CMS 105 sees that another MCD has a more recently generated authorization token, the CMS 105 may require additional verification to initiate the delay and notification process. For example, the CMS 105 can require that a customer service agent provide manual approval after the agent receives sufficient authentication information from the user of the MCD making the request. By using the authorization token in such a manner, the CMS 105 can automatically prevent a thief from initiating multiple delay and notification requests using a stolen MCD 104.

[0083] In some embodiments, a non-transitory computer-readable storage medium containing instructions is also provided, which can be executed by a device to perform the above-described methods. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, a hard disk, a solid-state drive, a magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROM, EPROM, FLASH-EPROM, or any other flash memory, NVRAM, cache memory, registers, any other memory chip or cartridge, and networked versions thereof. A device may include one or more processors (CPUs), input / output interfaces, network interfaces, and / or memory.

[0084] The devices, modules, and other functional units described in this disclosure may be implemented by hardware, or software, or a combination of hardware and software. In some embodiments, functionality described as being implemented in hardware may instead be implemented in software, or a combination of hardware and software. Similarly, in some embodiments, functionality described as being implemented in software may instead be implemented in hardware, or a combination of hardware and software. If something is implemented in software, it may be stored in a non-transitory computer-readable medium, such as the computer-readable medium described above. Such software, when executed by a processor, may perform the functions of the device, module, or other functional unit it implements. The devices, modules, and other functional units described above may also be combined or further divided into multiple sub-units.

[0085] In some places, reference is made to standards that contain standard ways of performing certain tasks. These standards are revised from time to time, and unless expressly stated otherwise, references to standards in this disclosure refer to the latest published standard at the time of filing.

[0086] Spatially relative terms such as "under," "below," "lower," "over," and "upper" may be used herein simply to describe the relationship of one element or feature to other elements when the device is in a proper up-down relationship.

[0087] When a feature is referred to as "on" another feature, the feature may be directly on the other feature with no intervening features present, or may be indirectly on the other feature with intervening features present. In contrast, when a feature is referred to as "directly on" another feature, the feature is directly on the other feature with no intervening features present. When a feature is referred to as being "connected," "attached," or "coupled" to another feature, it will also be understood that the feature may be directly connected, attached, or coupled to the other feature with no intervening features present, or may be indirectly connected, attached, or coupled to the other feature with intervening features present. In contrast, when a feature is referred to as being "directly connected," "directly attached," or "directly coupled" to another feature, the feature is directly connected, attached, or coupled with no intervening features present.

[0088] The terms "about" and "approximately" generally refer to an acceptable degree of error or variation in the measured quantity, given the nature or precision of the measurement. Typical exemplary degrees of error or variation are within 20%, preferably within 10%, more preferably within 5%, and even more preferably within 1% of a given value or range of values. Numerical quantities described herein are approximate unless otherwise specified, and the term "about" or "approximately" means that they can be inferred if not explicitly stated.

[0089] Ordinal numbers or terms such as "first" and "second" are used only to distinguish one entity or operation from another and do not require or imply any actual relationship or sequence between those entities or operations. Thus, a first feature or element could be referred to as a second feature or element, and similarly, a second feature or element could be referred to as the first feature or element without departing from the teachings of this disclosure. Furthermore, the words "comprising," "having," "containing," and "including," as well as other similar forms, are intended to mean that the item or items following any one of these words is an inclusive list of such items or items, or that the item or items following the list are limited only to, and not limited to, the listed items.

[0090] As used herein, unless otherwise stated, the terms "or" and "at least one of" encompass all possible combinations unless impracticable. For example, if it is stated that a component may include "A or B," then, unless specifically stated or impracticable, the component may include "A," "B," or "A and B." As a second example, if it is stated that a component includes "at least one of A, B, or C," then, unless specifically stated or impracticable, the component may include "A," "B," "C," "A and B," "A and C," "B and C," or "A, B, and C." This same structure applies to longer lists (e.g., "A, B, C, or D").

[0091] As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0092] Any statement in this disclosure criticizing or disparaging an aspect of the prior art is not intended to indicate that what is claimed excludes any of the criticized or disparaged aspects of the prior art.

[0093] Any given element or step of the above-disclosed embodiments may be embodied in a single element or step, or in multiple elements or steps. Further, any given element or step of the above-disclosed embodiments may be combined and embodied in a single element or step, or in multiple elements or steps.

[0094] The sequence of steps depicted in the various figures is for illustrative purposes only and does not necessarily indicate that embodiments of the present disclosure are limited to any particular sequence of steps. Thus, steps performed by various embodiments of the present disclosure may be performed in different orders while implementing the same method.

[0095] In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Certain adaptations and modifications of the described embodiments may be made. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The specification and embodiments are intended to be exemplary only, with the true scope and spirit of the invention being set forth in the following claims. It is also intended that the order of steps depicted in the figures is for illustrative purposes only and is not intended to be limited to any particular order of steps. Thus, one skilled in the art will appreciate that these steps may be performed in different orders while performing the same method.

[0096] Embodiments of the present disclosure can be implemented according to at least the following clauses.

[0097] Clause 1: A cryptocurrency management system comprising: a mobile communications device (MCD) configured to generate a first authentication signature for use in authenticating transactions involving a cryptocurrency multi-signature address of a cryptocurrency network based on a first private key stored by the MCD; a cloud server configured to store, at a cloud server associated with the MCD, an encrypted backup of the first private key encrypted using an MCD backup encryption key provided to the CMS; and a cryptocurrency management server (CMS) configured to generate a second authentication signature for use in authenticating transactions involving the cryptocurrency multi-signature address of the cryptocurrency network based on a second private key stored by the CMS, the second private key being associated with a first user account; the CMS of the cryptocurrency management system receiving an MCD backup key request, wherein the MCD backup key recovery request is initiated in accordance with a security policy of the first user account for cryptocurrency multi-signature. a process for providing an MCD backup encryption key to a first user, the process being configured to verify the MCD backup key request originating from the first user in response to receiving an MCD backup key request, the process comprising: sending one or more sets of social recovery credentials to the first user, each of the one or more sets of social recovery credentials associated with a corresponding social recovery contact from a set of one or more social recovery contacts indicated by a security policy; receiving one or more social recovery verification messages each indicating the MCD backup key request originating from the first user, each of the one or more social recovery verification messages received from a corresponding social recovery contact and based on the set of social recovery credentials associated with the corresponding social recovery contact; and sending the one or more sets of social recovery credentials to the set of one or more social recovery contacts indicated by the security policy;receiving corresponding social recovery confirmation messages, each of which confirms the MCD backup key request originating from the first user, wherein the one or more sets of social recovery credentials are associated with a corresponding social recovery contact from the set of one or more social recovery contacts, and wherein each of the one or more social recovery confirmation messages is based on the set of credentials associated with the corresponding social recovery contact; and transmitting an MCD backup encryption key to the first user in response to receiving the one or more social recovery confirmation messages and verifying the MCD backup key request originating from the first user.

[0098] Clause 2: The system of clause 1, further configured to: recover the first private key by retrieving an encrypted backup of the first private key from a cloud server associated with the MCD and decrypting the retrieved encrypted backup of the first private key using the MCD backup encryption key sent to the first user by the CMS.

[0099] Clause 3: The cryptocurrency management system of any of clauses 1-2, wherein the CMS is further configured to: process one or more received social recovery verification messages, verifying that each received social verification message is based on a set of social recovery credentials comprising the social recovery verification message and corresponds to a set of social recovery credentials for a corresponding social recovery contact; and in response to verifying that each of the one or more received social verification messages is based on a respective set of social recovery credentials associated with the corresponding social recovery contact, send the MCD backup cryptographic key to the first user.

[0100] Clause 4: A cryptocurrency management system as described in any of clauses 1-3, wherein the set of social recovery information sent by the CMS comprises at least a first number of sets of social recovery credentials, and the received one or more social recovery verification messages comprise one or more social recovery verification messages collectively based on at least a second number of sets of social recovery credentials, the second number being less than or equal to the first number, and each of the at least second number of sets of social recovery credentials being associated with a different social recovery contact.

[0101] Clause 5: The cryptocurrency management system of any of clauses 1-4, wherein the CMS and the first user account are associated with a first online platform, and the MCD backup key request is generated by using the first user account to access the first online platform.

[0102] Clause 6: The cryptocurrency management system of clause 5, wherein the one or more social recovery verification messages are received from the first user, the one or more social recovery verification messages including information based on a password associated with a login to the first user account, and the CMS is further configured to process the one or more received social recovery verification messages to verify that each received social verification message is based on information derived from a password associated with the first user account.

[0103] Clause 7: The cryptocurrency management system of any of clauses 1-6, wherein the CMS is further configured to: receive a transaction request involving one or more cryptocurrency tokens associated with the cryptocurrency multi-signature address, the transaction request comprising either a first authentication signature or a second authentication signature; and, in response to receiving the transaction request, generate an authenticated transaction using the third authentication signature and either the first authentication signature or the second authentication signature; and submit the authenticated transaction to the cryptocurrency network.

[0104] Clause 8: The cryptocurrency management system of clause 7, wherein the transaction request comprises authentication information indicating that the transaction request is from the first user, and wherein the CMS is further configured to process the transaction request to verify the authentication information and generate the authenticated transaction in response to verifying the authentication information.

[0105] Clause 9: The cryptocurrency management system of clause 8, further configured: the CMS processes the transaction request to determine whether the transaction request conforms to a transaction policy of a first user account for the cryptocurrency multi-signature address; and in response to determining that the transaction request conforms to the transaction policy, generate an authenticated transaction.

[0106] Clause 10: The cryptocurrency management system of clause 9, wherein the transaction policy requires the initiated transaction to be in value less than a certain amount.

[0107] Clause 11: A method for managing cryptocurrency, comprising: generating a first authentication signature for use in authenticating transactions involving a cryptocurrency multi-signature address of a cryptocurrency network based on a first private key stored by a cryptocurrency management server (CMS), the first private key being associated with a first user account of a first user on the CMS; receiving a mobile communications device (MCD) backup key request configured to initiate a process for providing an MCD backup cryptographic key to the first user in accordance with a security policy of the first user account for the cryptocurrency multi-signature address; the second private key being stored by the MCD configured to use the second private key to generate a second authentication signature for use in authenticating transactions involving the cryptocurrency multi-signature address of the cryptocurrency network; and storing an encrypted copy of the second private key by the MCD on a cloud server associated with the MCD; the encrypted copy of the second private key is encrypted using the second private key; the MCD backup encryption key is stored by a cryptocurrency management device (CMD), and the third private key is configured to use the third private key to generate a third authentication signature for use in authenticating transactions involving the cryptocurrency multi-signature address on the cryptocurrency network; in response to receiving the MCD backup key request, verifying the MCD backup key request originated from the first user and sending one or more sets of social recovery credentials to the first user, each of the one or more sets of social recovery credentials being associated with a corresponding social recovery contact from a collection of one or more social recovery contacts indicated by the security policy; and receiving one or more social recovery verification messages indicating that the corresponding social recovery contacts each confirm the MCD backup key request originated from the first user;The method includes: sending one or more social recovery verification messages to a collection of one or more social recovery credentials indicated by a security policy, each of the one or more sets of corresponding social recovery credentials being associated with a corresponding social recovery contact from the collection of one or more social recovery contacts; receiving one or more social recovery verification messages, each indicating a corresponding social recovery contact, each of the one or more social recovery verification messages being based on the set of credentials associated with the corresponding social recovery contact; and sending an MCD backup encryption key to the first user in response to receiving the one or more social recovery verification messages and verifying an MCD backup key request originating from the first user.

[0108] Clause 12: The method of clause 11, further comprising retrieving, by the MCD, an encrypted backup of the second private key from a cloud server associated with the MCD, and recovering, by the MCD, the second private key, wherein the MCD recovers the second private key by decrypting the retrieved encrypted backup of the second private key using the MCD backup encryption key sent to the first user by the CMS.

[0109] Clause 13: The method of any of clauses 11-12, wherein sending the sets of social recovery credentials comprises sending at least a first number of the sets of social recovery credentials, and receiving the one or more social recovery verification messages comprises receiving one or more social recovery verification messages collectively based on at least a second number of the sets of social recovery credentials, the second number being less than or equal to the first number, and each of the at least second number of the sets of social recovery credentials being associated with a different social recovery contact.

[0110] Clause 14: A method described in any of clauses 11 to 13, further comprising: processing one or more received social verification messages to verify that each received social verification message is based on a set of social recovery credentials for a corresponding social recovery contact; and sending an MCD backup encryption key to the first user in response to verifying that each of the one or more received social verification messages is based on a respective set of social recovery credentials associated with the corresponding social recovery contact.

[0111] Clause 15: The method of any of clauses 11 to 14, wherein a first user account is associated with a first online platform, and the MCD backup key request is generated by using the first user account to access the first online platform.

[0112] Clause 16: The method of clause 15, wherein one or more social recovery verification messages are received from a first user, each of the one or more received social recovery verification messages including information based on a password associated with logging into the first user account, the method further comprising processing the received one or more social recovery verification messages to verify each of the one or more received social recovery verification messages based on information retrieved from the password associated with the first user account.

[0113] Clause 17: The method of any of clauses 11-16, further comprising: receiving a transaction request involving one or more cryptocurrency tokens associated with the cryptocurrency multi-signature address, the transaction request including either the second authentication signature or the third authentication signature, and the transaction request including authentication information indicating that the transaction request is from the first user; processing the transaction request to verify the authentication information; in response to verifying the authentication information, generating an authenticated transaction using the first authentication signature and either the second authentication signature or the third authentication signature; and submitting the authenticated transaction to the cryptocurrency network.

[0114] Clause 18: The method of clause 17, further comprising: processing the transaction request to determine whether the transaction request complies with a transaction policy of a first user account for the cryptocurrency multi-signature address; and generating an authenticated transaction in response to determining that the transaction request complies with the transaction policy.

[0115] Clause 19: When executed by at least one processor, the method causes the at least one processor to: generate, based on a first private key stored by a cryptocurrency management server (CMS), a first authentication signature for use in authenticating transactions involving a cryptocurrency multi-signature address on a cryptocurrency network, the first private key being associated with a first user account of a first user on the CMS; the MCD backup key request being configured to initiate a process to provide an MCD backup cryptographic key to the first user in accordance with a security policy of the first user account for the cryptocurrency multi-signature address; the second private key being stored by an MCD configured to generate, using the second private key, a second authentication signature for use in authenticating transactions involving the cryptocurrency multi-signature address on the cryptocurrency network; the MCD further configured to store an encrypted copy of the second private key, the encrypted copy of the second private key being encrypted using the MCD backup cryptographic key; the third private key is encrypted using the third private key, the third private key is stored by a cryptocurrency management device (CMD), the third private key is configured to generate a third authentication signature for use in authenticating transactions involving a cryptocurrency multi-signature address of the cryptocurrency network; and in response to receiving the MCD backup key request, verifying the MCD backup key request originated from the first user comprises sending one or more sets of social recovery credentials to the first user, each of the one or more sets of social recovery credentials being associated with a corresponding social recovery contact from a collection of one or more social recovery contacts indicated by a security policy; and receiving one or more social recovery verification messages indicating that the corresponding social recovery contacts each verify the MCD backup key request originated from the first user, based on the set of corresponding social recovery credentials;or a set of one or more social recovery credentials indicated by a security policy, wherein each of the one or more sets of social recovery credentials is associated with a corresponding respective social recovery contact from a collection of one or more social recovery contacts; and receiving one or more social recovery verification messages from the first user, each indicating that the corresponding social recovery contact confirms the MCD backup key request originated from the first user, wherein each of the one or more social recovery verification messages is based on the set of credentials associated with the corresponding social recovery contact.

[0116] Clause 20: The non-transitory computer-readable medium of clause 19, wherein the instructions further cause the at least one processor to manage cryptocurrency by retrieving, by the MCD, the encrypted backup of the second private key from the cloud server associated with the MCD and recovering, by the MCD, the second private key, wherein the MCD recovers the second private key by decrypting the retrieved encrypted backup of the second private key using the MCD backup cryptographic key sent to the first user by the CMS.

[0117] Clause 21: The non-transitory computer-readable medium of any of clauses 19 to 20, wherein the instructions further cause the at least one processor to process the one or more received social recovery verification messages for each received social recovery verification message based on a set of social recovery credentials of a corresponding social recovery contact, and in response to verifying that each of the one or more received social verification messages is based on a respective set of social recovery credentials associated with the corresponding social recovery contact, manage cryptocurrency by sending the MCD backup cryptographic key to the first user.

[0118] Clause 22: A non-transitory computer-readable medium described in any of clauses 19 to 21, wherein sending the set of social recovery credentials comprises sending at least a first number of sets of social recovery credentials, and receiving the one or more social recovery verification messages comprises receiving one or more social recovery verification messages collectively based on at least a second number of sets of social recovery credentials, the second number being less than or equal to the first number, and each of the at least second number of sets of social recovery credentials being associated with a different social recovery contact.

[0119] Clause 23: A non-transitory computer-readable medium described in any of clauses 19 to 22, wherein a first user account is associated with a first online platform and the key recovery request is generated by using the first user account to access the first online platform.

[0120] Clause 24: The non-transitory computer-readable medium of clause 23, further comprising: receiving one or more social recovery verification messages from a first user, each of the one or more received social recovery verification messages comprising information based on a password associated with logging into the first user account; and processing the received one or more social recovery verification messages to verify that each of the received social recovery verification messages is based on information derived from the password associated with the first user account.

[0121] Clause 25: The non-transitory computer-readable medium of any one of Clauses 19 to 24, wherein the instructions further cause the at least one processor to manage cryptocurrency by receiving a transaction request involving one or more cryptocurrency tokens associated with a cryptocurrency multi-signature address, the transaction request including either the second authentication signature or the third authentication signature, and the transaction request including authentication information indicating the transaction request is from the first user; processing the transaction request to verify the authentication information; generating the authenticated transaction using the first authentication signature and either the second authentication signature or the third authentication signature in response to verifying the authentication information; and submitting the authenticated transaction to the cryptocurrency network.

[0122] Clause 26: The non-transitory computer-readable medium of Clause 25, wherein the instructions further cause the at least one processor to manage cryptocurrency by processing the transaction request to determine whether the transaction request conforms to a transaction policy of the first user account for the cryptocurrency multi-signature address, and generating the authenticated transaction in response to determining that the transaction request conforms to the transaction policy.

Claims

1. A cryptocurrency management system, A mobile communication device (MCD), comprising: generating a first authentication signature based on a first private key stored by the MCD for use in authenticating a transaction involving a cryptocurrency multi-signature address on a cryptocurrency network; storing, on a cloud server associated with the MCD, an encrypted backup of the first private key, the encrypted backup of the first private key being encrypted using an MCD backup encryption key provided to a Cryptocurrency Management Server (CMS); An MCD configured as follows: The cryptocurrency management server (CMS), generating a second authentication signature for use in authenticating a transaction involving a cryptocurrency multi-signature address on the cryptocurrency network based on a second private key stored by the CMS, the second private key being associated with a first user account of a first user on the CMS; receiving an MCD backup key recovery request, the MCD backup key recovery request configured to initiate a process for providing the MCD backup cryptographic key to the first user in accordance with a security policy of the first user account for the cryptocurrency multi-signature address; In response to receiving the MCD backup key request, verifying the MCD backup key request originated from the first user; transmitting one or more sets of social recovery credentials to the first user, each of the one or more sets of social recovery credentials associated with a corresponding social recovery contact from a set of one or more social recovery contacts indicated by the security policy; receiving one or more social recovery verification messages, each indicating that a corresponding social recovery contact has confirmed the MCD backup key request originating from the first user, wherein each of the one or more social recovery verification messages is received from the corresponding social recovery contact and is based on the set of social recovery credentials associated with the corresponding social recovery contact; or transmitting one or more sets of social recovery credentials to a set of one or more social recovery contacts indicated by the security policy, each of the one or more sets of social recovery credentials associated with a corresponding social recovery contact from the set of one or more social recovery contacts; receiving one or more social recovery verification messages indicating that a corresponding social recovery contact confirms the MCD backup key request originating from the first user, each of the one or more social recovery verification messages based on the set of authentication information associated with the corresponding social recovery contact; and verifying by either sending the MCD backup encryption key to the first user in response to receiving the one or more social recovery verification messages and verifying the MCD backup key request originating from the first user; A CMS configured as follows: Cryptocurrency management systems, including:

2. 10. The system of claim 1, wherein the MCD further comprises: Retrieving the encrypted backup of the first private key from the cloud server associated with the MCD; recovering the first private key by decrypting the retrieved encrypted backup of the first private key using the MCD backup encryption key sent by the CMS to the first user; A cryptocurrency management system that is further composed of:

3. 3. The cryptocurrency management system according to claim 1 or 2, wherein the CMS further comprises: processing the one or more received social recovery verification messages to verify that each received social verification message is based on a set of social recovery credentials, the social recovery verification message corresponding to a set of social recovery credentials of a corresponding social recovery contact; sending, to the first user, the MCD backup encryption key in response to verifying that each of the one or more received social verification messages is based on a respective set of social recovery credentials associated with a corresponding social recovery contact; A cryptocurrency management system configured to:

4. 4. The cryptocurrency management system according to claim 1, the set of social recovery information transmitted by the CMS includes at least a first number of sets of social recovery credentials; the received one or more social recovery verification messages include one or more social recovery verification messages collectively based on at least a second number of sets of social recovery credentials; the second number is less than or equal to the first number; Each of the at least a second number of sets of social recovery credentials is associated with a different social recovery contact.

5. 5. The cryptocurrency management system according to claim 1, the CMS and the first user account are associated with a first online platform; The cryptocurrency management system, wherein the MCD backup key request is generated by accessing the first online platform using the first user account.

6. The cryptocurrency management system according to claim 5, the one or more social recovery verification messages are received from the first user; each of the one or more received social recovery verification messages includes information based on a password associated with logging into the first user account; the CMS is further configured to process the one or more received social recovery verification messages to verify that each received social verification message is based on the information retrieved from the password associated with the first user account.

7. 7. The cryptocurrency management system according to claim 1, wherein the CMS further comprises: receiving a transaction request involving one or more cryptocurrency tokens associated with the cryptocurrency multi-signature address, the transaction request comprising either the first authentication signature or the second authentication signature; In response to receiving the transaction request, generating an authenticated transaction using the third authentication signature and either the first authentication signature or the second authentication signature; and a cryptocurrency management system configured to submit the authenticated transaction to the cryptocurrency network.

8. The cryptocurrency management system according to claim 7, the transaction request includes authentication information indicating that the transaction request is from the first user; The CMS further comprises: processing the transaction request to verify the authentication information; generating the authenticated transaction in response to verifying the authentication information; A cryptocurrency management system configured to:

9. 9. The cryptocurrency management system according to claim 8, wherein the CMS further comprises: processing the transaction request to determine whether the transaction request conforms to a transaction policy of the first user account for the cryptocurrency multi-signature address; generating the authenticated transaction in response to determining that the transaction request complies with the transaction policy; A cryptocurrency management system configured to:

10. 10. The cryptocurrency management system of claim 9, wherein the transaction policy requires the initiated transaction to be less than a predetermined amount in value.

11. A method of managing cryptocurrency, comprising: generating a first authentication signature for use in an authentication transaction involving a cryptocurrency multi-signature address of a cryptocurrency network based on a first private key stored by a cryptocurrency management server (CMS), the first private key being associated with a first user account of a first user on the CMS; receiving a mobile communication device (MCD) backup key request, the MCD backup key request configured to initiate a process for providing an MCD backup cryptographic key to the first user in accordance with a security policy of the first user account for the cryptocurrency multi-signature address; the second private key is stored by an MCD configured to use the second private key to generate a second authentication signature for use in authenticating transactions involving the cryptocurrency multi-signature address on the cryptocurrency network; the MCD is further configured to store an encrypted copy of the second private key on a cloud server associated with the MCD, the encrypted copy of the second private key being encrypted using the MCD backup encryption key; the third private key is stored by a cryptocurrency management device (CMD) configured to use the third private key to generate a third authentication signature for use in authenticating transactions involving the cryptocurrency multi-signature address on the cryptocurrency network; Receiving and In response to receiving the MCD backup key request, verifying the MCD backup key request originated from the first user; transmitting one or more sets of social recovery credentials to the first user, each of the one or more sets of social recovery credentials associated with a corresponding social recovery contact from a set of one or more social recovery contacts indicated by the security policy; receiving one or more social recovery verification messages, each of the one or more social recovery verification messages indicating a corresponding social recovery contact confirming the MCD backup key request originating from the first user, and each of the one or more social recovery verification messages received from the corresponding social recovery contact and based on the set of social recovery credentials associated with the corresponding social recovery contact; transmitting one or more sets of social recovery credentials to a set of one or more social recovery contacts indicated by the security policy, each of the one or more sets of social recovery credentials associated with a corresponding social recovery contact from the set of one or more social recovery contacts; receiving one or more social recovery verification messages, each of the one or more social recovery verification messages indicating a corresponding social recovery contact confirming the MCD backup key request originating from the first user, and each of the one or more social recovery verification messages based on a set of authentication information associated with the corresponding social recovery contact; and verifying by either sending the MCD backup encryption key to the first user in response to receiving the one or more social recovery verification messages and verifying the MCD backup key request originated from the first user; A method comprising:

12. 12. The method of claim 11, retrieving, by the MCD, the encrypted backup of the second private key from the cloud server associated with the MCD; recovering, by the MCD, the second private key, wherein the MCD recovers the second private key by decrypting the retrieved encrypted backup of the second private key using the MCD backup encryption key sent to the first user by the CMS; The method further comprises:

13. 13. The method of claim 11 or 12, transmitting the set of social recovery credentials includes transmitting at least a first number of sets of social recovery credentials; receiving the one or more social recovery verification messages includes receiving one or more social recovery verification messages collectively based on at least a second number of sets of social recovery credentials; the second number is less than or equal to the first number; A method, wherein each of the at least second number of sets of social recovery credentials is associated with a different social recovery contact.

14. 14. The method according to any one of claims 11 to 13, processing the one or more received social recovery verification messages to verify that each received social verification message is based on a set of social recovery credentials of a corresponding social recovery contact; sending an MCD backup encryption key to the first user in response to verifying that each of the one or more received social verification messages is based on a distinct set of social recovery credentials associated with a corresponding social recovery contact; The method further comprises:

15. 15. The method according to any one of claims 11 to 14, the first user account is associated with a first online platform; The method, wherein the MCD backup key request is generated by accessing the first online platform using the first user account.

16. 16. The method of claim 15, the one or more social recovery verification messages are received from the first user; each of the one or more received social recovery verification messages includes information based on a password associated with logging into the first user account; The method further includes processing the one or more received social recovery verification messages to verify that each received social verification message is based on information retrieved from the password associated with the first user account.

17. 17. The method of any one of claims 11 to 16, receiving a transaction request involving one or more cryptocurrency tokens associated with the cryptocurrency multi-signature address; the transaction request includes either the second authentication signature or the third authentication signature; the transaction request includes authentication information indicating that the transaction request is from the first user; Receiving and processing the transaction request to verify the authentication information; generating an authenticated transaction using the first authentication signature and either the second authentication signature or the third authentication signature in response to verifying the authentication information; submitting the authenticated transaction to the cryptocurrency network; The method further comprises:

18. 18. The method of claim 17, processing the transaction request to determine whether the transaction request conforms to a transaction policy of the first user account for the cryptocurrency multi-signature address; generating the authenticated transaction in response to determining that the transaction request complies with the transaction policy; The method further comprises:

Images