Methods and systems for managing cryptocurrencies

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 the benefit of priority of U.S. Utility Patent Application No. 18 / 223,486, filed Jul. 18, 2023, which claims the benefit of priority of U.S. Provisional Patent Application No. 63 / 396,208, filed Aug. 8, 2022, both of which are hereby incorporated by reference in their entirety.

[0002] (Technical Field) Cryptocurrencies such as Bitcoin are gaining popularity and have many advantages. In this regard, cryptocurrencies provide a digital form of currency that can be transferred from one party to another via a global computer network such as the Internet, thereby facilitating the storage and transfer of financial assets for financial transactions. This digital nature enables cryptocurrencies to offer a number of benefits that are not possible with more traditional currencies. However, the digital nature of cryptocurrencies also presents unique challenges. For example, accessing and controlling cryptocurrency assets using cryptographic keys can involve the user maintaining and storing these keys. This can increase the complexity for the user and increase the likelihood that the user may lose access to their cryptocurrency assets by losing the stored cryptographic keys. Additionally, the storage of these cryptographic keys can also increase the likelihood that malicious actors can access the user's stored cryptographic keys and subsequently steal the user's cryptocurrency assets.

[0003] In particular, cryptocurrency users often face the choice between third-party custody and self-custody. Third-party custody relies on a third party to hold information such as private keys used to establish ownership and transfer cryptocurrency. Such a solution may be attractive to users who do not want to bear much of the complexity of holding, handling, and transferring information related to cryptocurrency. However, many users may have concerns about the security measures that a third-party custodian uses to keep cryptocurrency safe, and their ability to access the cryptocurrency from the third-party custodian in the event of bankruptcy or other unforeseen events such as the loss of a certificate of credit required by the third-party custodian. In the case of self-custody, the owner 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 their cryptocurrency in the event of loss or damage to the hardware used to store and otherwise manage the cryptocurrency. [Brief explanation of the drawing]

[0004] This disclosure can be better understood with reference to the following drawings. The elements in the drawings are not necessarily at a constant scale relative to one another, and the emphasis is on clearly illustrating the principles of this disclosure. Furthermore, similar reference numerals indicate corresponding parts throughout several drawings.

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

[0006] [Figure 2] Figure 2 is a flowchart illustrating an exemplary method using social recovery.

[0007] [Figure 3A] Figure 3A shows the graphical user interface (GUI) for using social recovery. [Figure 3B]Figure 3B shows the graphical user interface (GUI) for using social recovery.

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

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

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

[0011] [Figure 7] Figure 7 shows a front view and a rear view of an exemplary mobile communication device, as shown in Figure 5.

[0012] [Figure 8] Figure 8 is a flowchart illustrating an exemplary method using delays and notifications. [Modes for carrying out the invention]

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

[0014] In some embodiments of this disclosure, the MCD has an application that controls the management of cryptocurrency in general. Certain data used by the application (such as various private keys) is backed up by storing encrypted copies of the data on a cloud server, and the key copies are used to encrypt the backup data provided to the CMS. If the original MCD or application is 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, in order for the MCD to recover the private keys stored in the original MCD, it may communicate with the CMS to encrypt the backup and obtain a key used to decrypt the backup using the retrieved encryption key. In some embodiments, the user may be authenticated for key recovery or cryptocurrency transactions by providing biometric input to the MCD without requiring the user to provide a password, PIN, or other information to be stored, thereby increasing the flexibility of the system.

[0015] During the recovery of a lost private key, the system may be configured to delay the completion of financial transactions and provide notifications of pending financial transactions, thereby allowing authorized users to be notified of any transactions deemed fraudulent and subsequently canceled. In some embodiments, the system may also, upon notification of a lost key, implement at least several constraints during the recovery process, such as spending limits, thereby limiting the amount of funds that could be transferred by a fraudulent user potentially exploiting vulnerabilities in the recovery process.

[0016] In some embodiments, a registered authorized user is permitted to list social recovery contacts (contacts) that can be used for authentication in recovering lost keys. In this regard, when a key is lost, the system provides a code that allows the authorized user to communicate with 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 social recovery contacts provide a valid code, the system authenticates the user during the recovery process to enable the recovery of one or more lost keys. Thus, the authorized user can be authenticated without having to provide a password, PIN, or other information that the user must remember, thereby facilitating recovery.

[0017] Hereinafter, exemplary embodiments are given in detail, and examples thereof are shown in the accompanying drawings. Unless otherwise indicated, the following description refers to the accompanying drawings where the same number in different drawings represents the same or similar elements. The implementations described below in the exemplary embodiments do not represent all implementations consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with the aspects relating to the present invention described in the accompanying claims. Specific aspects of this disclosure are described in more detail below. Terms and definitions provided herein shall be governed by convention in case of any conflict with terms and / or definitions incorporated by standard.

[0018] One potential barrier to the more mainstream adoption of self-storage solutions is the need to create visually sensitive backup material and physically protect it to maintain security. This means moving away from reliance on long (e.g., 12 or 24 words) seed phrases that users record on a medium like paper or metal (for security). For such solutions, a malicious user who has even brief access to this material could potentially use it to steal or otherwise misuse cryptocurrency. Seed phrases have worked well for many experienced users. However, seed phrases can create an intimidating experience for new cryptocurrency users and provide relatively easy opportunities for malicious 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 already compromised seed phrases when setting up their wallets, or compromising customers' cloud storage accounts containing photos of physical seed phrase cards that came with their wallets. In addition, many users create secrets that are sometimes easy to remember but can also be vulnerable to hackers, like passwords, and in some cases, users can create secrets that are more secure but harder to remember. There is a general demand for techniques that provide robust security for assets like cryptocurrencies without requiring users to remember complex secrets (e.g., passwords).

[0019] For this purpose, it is generally desirable to enable the recovery of lost private keys without requiring the user to maintain backup materials or to relinquish control of their cryptocurrency account to a third party.

[0020] FIG. 1 is a simplified block diagram of a cryptocurrency management system. As shown in the figure, the 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 are a cryptocurrency network 106 and a cryptocurrency address 107 associated with one or more transactions within the cryptocurrency network 106. Generally, the MCD 104 can interact with the CMD 103 and the CMS 105, among other things, to generate and submit valid cryptocurrency transactions. As part of this process, the CMS 105 and the MCD 104 can also interact with the cryptocurrency network 106.

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

[0022] The private key 110 can be associated with a cryptocurrency management application (app) 113 running on the MCD 104 for the purpose of generally managing the cryptocurrency address 107. For this purpose, the cryptocurrency management app 113 can be associated with user account information 111 that is used to authenticate the MCD 104 to the CMS 105 and generally enables interaction between the cryptocurrency management app 113 and the MCD 105. The cryptocurrency management app can also be associated with app control logic 112, which includes instructions that can be executed by the 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 this disclosure, the functions described herein as being performed by the app control logic 112 may 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 organize the operation of the MCD 104 and manage cryptocurrencies according to the techniques described herein.

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

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

[0025] At a high level, the cryptocurrency management system 102 acts to manage the cryptocurrency address 107 by controlling the use of the cryptocurrency funds associated with the cryptocurrency address 107 in a transaction. In this regard, the cryptocurrency management system 102 can be considered an association of devices or systems that (1) each have a portion of the authority distributed to control the cryptocurrency address 107 and (2) are configured to cooperate with each other to use their collective authority to control the cryptocurrency address 107 (e.g., generate and submit associated transactions). In other words, the ability to manage the cryptocurrency address 107 is divided among the CMD 103, MCD 104, and CMS 105. In some embodiments, the CMD 103, MCD 104, and CMS 105 communicate with each other, obtain signatures for transactions, generate authenticated transactions, and agree on the transactions before they are 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 CMD103, MCD104, or CMS105. For example, there may be three private keys associated with the cryptocurrency address 107, and each of CMD103, MCD104, and CMS105 may store one of them, and each of CMD103, MCD104, and CMS105 may grant access to its private key only if the user can provide acceptable authentication credentials. Furthermore, the cryptocurrency address 107 may be configured to generate fully authenticated cryptocurrency transaction requests (requests) for cryptocurrency assets associated with the cryptocurrency address 107 using any two of the private keys. In other embodiments, a different number 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 ownership of CMD103 and MCD104, while CMS105 is maintained by a trusted third party. Furthermore, the owner may keep CMD103 in a secure location such as their home. Therefore, if MCD104 is stolen, it should be impossible for an unauthorized user to use MCD104 to generate fully authenticated cryptocurrency transactions involving the cryptocurrency assets associated with cryptocurrency address 107. This is because an unauthorized user (1) does not have physical access to or can not communicate with CMD103 (which, as mentioned above, may be designed to allow only short-range communication), and (2) cannot access the private key stored in CMS105 without providing a valid authentication certificate to CMS105.

[0028] In addition, when the owner wishes to initiate a transaction, the owner can transfer MCD104 to CMD103 or MCD104 to CMD103 so that CMD103 and MCD104 can communicate to generate a fully authenticated cryptocurrency transaction. In this regard, after providing CMD103 with a valid authentication certificate, CMD103 can use the private key stored therein to generate an authenticated signature to be communicated to CMD103, and CMD103 can use the private key stored therein to generate an authenticated signature that can be combined with the authenticated signature from CMD103 to generate a fully authenticated request for a cryptocurrency transaction. CMD103 can then send such a request to the cryptocurrency network 106. Thus, fully authenticated cryptocurrency transactions can be generated without using CMS105 using devices within the owner's physical possession (i.e., CMD103 and MCD104), thereby giving the owner complete control over cryptocurrency transactions in the event that CMS105 becomes unavailable for any reason. However, CMS105 remains available for recovery if CMD103 and / or MCD104 are lost, stolen, failed, or unavailable.

[0029] Specifically, if the original MCD104 is lost or otherwise unavailable, it can be replaced by a new MCD104 that can communicate with CMD103 and CMS105 to obtain two authenticated signatures that can be combined to form a fully authenticated cryptocurrency transaction. Also, if CMD103 is lost or otherwise unavailable, MCD104 can communicate with CMS105 (as described above for CMD103) to obtain an authenticated signature, which can then be combined with the authenticated signature from MCD104 to generate a fully authenticated cryptocurrency transaction. Thus, the embodiment shown by Figure 1 and described above provides the owner with flexibility while maintaining security and also allows for recovery in the event that any of CMD103, MCD104, or CMS105 is lost.

[0030] Furthermore, the cryptocurrency management system 102 can also enable the recovery of lost keys. Specifically, in some embodiments, the CMS 105 may be used to recover a lost private key 110, such as one that may occur through the loss or failure of the MCD 104. For example, in an exemplary embodiment, if a user loses access to the private key 110, the user can retrieve the MCD private key encrypted backup 116 from the cloud server 115 and the MCD backup encrypted key 117 from the CMS 105 in order 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, the CMS 105 may require the user to prove their identity as the owner of cryptocurrency address 107 through a process hereafter referred to as “social recovery,” in which information from a specific trusted party is used. In this regard, when the user has set up user account 118, the user may provide contact information (e.g., phone number, email address, user handle with a service provider, or similar identifier) ​​of at least one social recovery contact (contact person) that can be used to help recover or authenticate the recovery of lost keys. The user can then use user account 118 to communicate with the CMS 105 and initiate the recovery process, for example, through an application on MCD 104 or through an online web portal of the relevant online platform. In response, the CMS 105 may be configured to provide each 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 from the social recovery contact and instruct the CMS 105 to provide the set of credentials. The social recovery contact may be instructed to provide the sent set of credentials to the user of user account 118.

[0032] After the user of user account 118 has retrieved a sufficient number of social recovery credentials, the user can provide the retrieved set of social recovery credentials to CMS 105. The set of social recovery credentials may be provided to CMS 105 as part of a social recovery verification message, which may include additional information from the user, such as the password (or a hash derived from it) associated with user account 118. If the user provides a sufficient number of the correct set of social recovery credentials, along with potentially other necessary information (e.g., the password (or a hash derived from it) associated with user account 118), CMS 105 can provide the user with the MCD backup encryption key 117, for example, by directly sending the MCD backup encryption key 117 to MCD 104.

[0033] Alternatively, in some embodiments, the process may be reversed by the user of user account 118 receiving one or more sets of social recovery credentials associated with the social recovery contacts of 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 relevant online platform. In parallel, the social recovery contacts may be provided with a message indicating that the key recovery process has been initiated for user account 118 and a link to a website where the social recovery contacts can enter the set of social recovery credentials they received from the owner of user account 118. Naturally, the willingness of the social recovery contacts to comply with entering the set of social recovery credentials into the website depends largely on the contacts' assessment of whether the owner of 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 user account 118, the CMS 105 may provide the MCD backup encryption key 117 to the users, for example, by directly sending the MCD backup encryption key 117 to the MCD 104.

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

[0035] In yet another embodiment, the owner of user account 118 identifies a social recovery contact, and before the key recovery process is initiated for 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 user account 118 and requesting the contact to install an application on their mobile device to assist in the subsequent key recovery process. The CMS 105 can then use the application installed on the social recovery contact's mobile device to authenticate that the owner of user account 118 has initiated the process. In some embodiments, the installed application may be partially or temporarily installed. For example, the installed application may provide application data for storage on a cloud backup, the mobile device can then uninstall the application, and when the social recovery contact is prompted to participate in the social recovery process, the social recovery contact can reinstall the application and 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 prompted to download and run an application that performs the functions of the installed application without installing the application itself.

[0036] Figure 2 is a flowchart illustrating the process of 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 the original MCD104, or after installing (and configuring) the cryptocurrency management app 113 on a new MCD104 (for example, after the original MCD104 is lost and replaced with a new MCD104). In some embodiments, this process may be used in particular when access to the private key 110 is lost while access to the CMD103 is also lost.

[0037] First, as shown by block 202 in Figure 2, the owner of a user account can interact with the CMS to submit a key recovery request. In some embodiments, this may involve the user logging into user account 118 via the cryptocurrency management app 113, which then sends the key recovery request from MCD 104 to CMS 105. Alternatively, in some embodiments, the user can log into user account 118 through an online web portal associated with CMS 105 and submit a key recovery request to CMS 105 through this web portal. In some embodiments, before CMS 105 can act on the recovery request, it may require the user to provide credentials indicating a request from the owner of user account 118. For example, in some embodiments, CMS 105 may require the user to provide login credentials (e.g., username and password) used to access user account 118. As another example, CMS 105 may require the user to generate a valid signature of a hash of the data provided to the user by CMS 105 using one of the private keys associated with cryptocurrency address 107, such as private key 108. CMS105 can then use the corresponding public key to verify the authenticity of the signature and 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 can receive the request and initiate a recovery procedure according to the security policy of the user account for the cryptocurrency address. More precisely, as shown by block 203 in Figure 2, the CMS may receive the key recovery request and, using the social recovery contact information specified by the user account's security policy, send a set of social recovery credentials to each of one or more social recovery contacts. Generally, a security policy specifies certain configuration options that control the CMS's response to specific actions and the requirements that the CMS imposes before performing those actions. For example, in some embodiments, the CMS 105 will attempt to participate in the authentication of a cryptocurrency transaction requested by a user logged into user account 118 if the requested transaction is less than a certain value. This value can be set as part of a subset of security policies known as the transaction policy. As another example, security policy 116 may specify whether the CMS 105 will participate in the key recovery operation (i.e., whether it is willing to act on the key recovery request) and the requirements that the CMS 105 imposes before doing so. If CMS105 requires social recovery, security policy 116 may also list contact information for one or more social recovery contacts.

[0039] For example, CMS 105 may determine that the security policy 116 for a user indicates that social recovery contacts 121, 122, and 123 are social recovery contacts for user account 118, and based on that determination, it uses the social recovery contact information 124 indicated by the security policy 116 to send a set of social recovery authentication information to social recovery contacts 121, 122, and 123. Specifically, CMS can use the social recovery contact information indicated by the security policy for social recovery contacts to send a set of social recovery authentication information to social recovery contacts. Similarly, CMS can use the social recovery contact information indicated by the security policy for social recovery contacts to send a set of social recovery authentication information to social recovery contacts, and can use the social recovery contact information indicated by the security policy for social recovery contacts to send a set of social recovery authentication information to 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, such as eight or eleven digits, may be used. 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, such as an eight-character word or a nine-character word, may be used.

[0041] After a set of social recovery credentials has been sent to each social recovery contact through their respective social recovery contact information, each social recovery contact may receive, or otherwise obtain, access to their respective sets of social recovery credentials, as shown by block 204 in Figure 2. For example, if a social recovery contact's contact information is a phone number, the social recovery contact may receive the set of social recovery credentials via the smartphone device associated with that phone number. As another example, if a social recovery contact's contact information is an email address, the social recovery contact may receive the set of social recovery credentials via email received by a device (e.g., a smartphone, tablet, or personal computer (PC)) that has access to the inbox associated with that email address.

[0042] As shown by block 205 in Figure 2, after a set of social recovery credentials has been received by a social recovery contact, the social recovery contact can provide each set of social recovery credentials to the owner of the user account. This may involve each social recovery contact communicating, for example, with the owner of user account 114 to verify that the owner of user account 118 initiated or otherwise authorized the key recovery request.

[0043] As shown by block 206 in Figure 2, after a social recovery contact sends its respective set 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 user account 118 can log in to 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 send the entered social recovery verification code from MCD 104 to CMS 105. Alternatively, in some embodiments, the owner of user account 118 can log in to user account 118 through an online web portal associated with CMS 105. The online web portal 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 associated online web portal can send the entered social recovery verification code to CMS 105 from the device on which the online web portal is running. Generally, social recovery verification codes can be sent to the MCD as part of the social recovery verification message.

[0044] Figures 3A and 3B illustrate the graphical user interface (GUI) for using social recovery. As shown in the figures, the account owner can initiate the process of authenticating a backup key recovery request using social recovery. Specifically, as shown in Figure 3A, the account owner can trigger CMS105 to send social recovery credentials to the social recovery contact specified in the account's security policy. Here, the social recovery credentials are represented by a four-digit numerical code. As shown in Figure 3B, the account owner can then receive the numerical code from the social recovery contact, for example by having the social recovery contact verbally communicate the code via video call, and complete the social recovery authentication process by entering the received numerical code.

[0045] As shown by block 207 in Figure 2, after the owner of user account 114 sends a social recovery verification code to CMS 105, CMS 105 can receive and verify the transmitted social recovery verification code. If a sufficient number of the social recovery verification codes provided by the owner of user account 114 match the social recovery verification codes sent by CMS 105 to the social recovery verification contact 120, CMS 105 can send the MCD backup encryption key 117 to the owner of user account 114.

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

[0047] As shown by block 209 in Figure 2, after the MCD 104 retrieves the MCD private key encrypted backup 116 and obtains the MCD backup encryption key 117 sent by the CMS 105, the MCD 104 can recover the private key 110 by using the MCD backup encryption key 117 to decrypt the MCD private key encrypted backup 116.

[0048] Figure 4 is a block diagram of a cryptocurrency management device (CMD), such as the CMD103 in Figure 1. As shown in the figure, the CMD103 may comprise at least one processor 403 connected to a communication interface 404 and memory 405. The CMD103 may be a standalone mobile device or other types of devices, such as a desktop device not designed for mobility. Generally, the processor 403 may interact with and control these components, as well as the other components of the CMD103, in order to coordinate the functionality of the device. The communication interface 404 may comprise circuitry configured to communicate with other devices via various communication channels.

[0049] For example, in some embodiments, the communication interface 404 may enable communication only via a short-range peer-to-peer communication channel (e.g., Bluetooth®, NFC (Near Field Communication), or RFID (Radio Frequency Identification)). Alternatively, in some embodiments, the communication interface 404 may use a network such as the Internet. As an example, the communication interface 404 may wirelessly communicate with a modem, a wireless radio (e.g., a cellular transceiver), or other device, or with other devices designed to wirelessly 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 here, the communication interface 404 may be used to communicate with components of the cryptocurrency management system 102, such as the CMS 105 and MCD 104, as well as with the cryptocurrency network 106 (or certain nodes thereof).

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

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

[0052] In operation, the processor 403 can manage the cryptocurrency assets associated with the cryptocurrency address 107 by executing instructions of the device control logic 109. This may involve communicating with the CMS 105 and MCD 104 to obtain (or generate) authenticated signatures, as well as communicating with the cryptocurrency network 106 (or its nodes). In order to obtain a signature from the CMS 105 or MCD 104, the processor 403 can interact with the communication interface 404 to communicate with the CMS 105 and 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 Figure 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 and transmitted on any computer-readable medium for use by, or in connection with, an instruction execution device capable of fetching and executing instructions, such as a processor 403. In the context of this specification, “computer-readable medium” may be any means that can contain or store computer programs for use by, or in connection with, an instruction execution device.

[0054] In some embodiments, the CMD103 may have a biometric sensor 408 for authenticating an authorized user. For example, in some embodiments, the biosensor 408 is a fingerprint sensor located on the surface of the CMD103, but in other embodiments, other types of biosensors 408 are possible. Other embodiments may not have a biosensor.

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

[0056] In some embodiments, the CMD103 may have a small, tag-like form factor that, among other things, allows the CMD103 to be easily carried (portable). When the CMD103 is portable, it can be moved to a location associated with the transaction, i.e., the location of the sale of the product or service purchased with cryptocurrency, and as a result, there is no need to move the MCD104 to a secure location where the CMD103 is normally kept (e.g., the user's home). In other embodiments, the CMD103 may have a larger, less portable form factor.

[0057] Figure 5 is a block diagram of a mobile communication device (MCD), such as the MCD104 in Figure 1. While the MCD104 can be implemented as a smartphone, other types of MCD105 are possible, such as a laptop or other type of handheld device.

[0058] As shown in the diagram, the MCD104 may comprise at least one processor 503 connected to the network interface 504 and memory 505. Generally, the processor 503, like the other components of the MCD104, can interact with and control these components to adjust the functionality of the device. The network interface 504 may comprise circuitry configured to communicate with other devices over various networks, such as the Internet. As an example, the network interface 504 may comprise other devices designed to communicate with network access points, such as a modem, a wireless radio (e.g., a cellular transceiver), or a cellular tower, a network router, a Wi-Fi hotspot, or other types of access points.

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

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

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

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

[0063] In some embodiments, the MCD104 may also comprise an input device 508 and an output device 509. Generally speaking, the output device 503 is configured to communicate information to the user through some mechanism, such as a digital display. The processor 503 can interact with the output device 503 to send data to the user. Conversely, the input device 508 is configured to receive user input to the MCD104. For example, the 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 shown in this example, the input device 508 and the output device 509 may comprise the same device (e.g., a touchscreen display) in some embodiments. Furthermore, in some embodiments, either or both of the input device 508 and the output device 509 may comprise two or more physical devices.

[0064] Figure 6 is a block diagram of a cryptocurrency management server (CMS), such as the CMS105 in Figure 1. As shown in the figure, the CMS105 may comprise at least one processor 603 connected to a network interface 604 and memory 605. Generally, the processor 603 may interact with and control these components, as well as the other components of the CMS105, in order to coordinate the functionality of the device. The network interface 604 may comprise circuitry configured to communicate with other devices over various networks, such as the Internet. As an example, the network interface 604 may comprise other devices designed to communicate with network access points, such as a modem, a wireless radio (e.g., a cellular transceiver), or a cellular tower, network router, Wi-Fi hotspot, or other type of access point. Generally, as relevant here, the network interface 604 may be used to communicate with components of the cryptocurrency management system 102, such as the CMD103 and MCD104, as well as with the cryptocurrency network 106 (of a particular node).

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

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

[0067] It should be noted that the server control logic 119 can be implemented in software, hardware, firmware, or any combination thereof. In the exemplary 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 can be stored and transmitted on any computer-readable medium for use by, or in connection with, an instruction execution device capable of fetching and executing instructions, such as a processor 603.

[0068] Figure 7 is a diagram of an exemplary MCD having the aforementioned digital screen. Specifically, the MCD 702 (also called smartphone 702) in Figure 7 is implemented as a smartphone having a touchscreen 705 on one side of the device (i.e., the device front 703) and a camera 706 on the opposite side (i.e., the device rear 704). The touchscreen 705 covers most of the device front 703 and implements both the input device 508 and output device 509 in Figure 5. The touchscreen 705 can output by displaying images or videos. The touchscreen 705 is also capable of receiving user input by forming taps, gestures, and other physical interactions with the screen. The processor and memory located inside the MCD 702, but functioning similarly to the processor 503 and memory 505 in Figure 5, are not shown.

[0069] During the recovery period, when a user has initiated key recovery using CMS105 but has not yet completed the process, CMS105 can implement additional security measures. In the background, if a key is permanently lost, the remaining two keys may still be used to generate transactions. If necessary, during the recovery process, various constraints, such as spending limits, may be implemented to allow minimal use of funds until the recovery process is complete. If necessary, during the recovery process, various constraints, such as spending limits, may be implemented to allow minimal use of funds until the recovery process is complete.

[0070] For example, in some embodiments, system 102 is configured to perform a process for transactions during the recovery process, hereafter referred to as “delay and notification processing.” In this regard, upon receiving notification of a permanently lost key, system 102 is configured to delay the transaction and provide notification of the transaction during the delay, thereby allowing an authorized user to take steps to stop or prevent the fraudulent transaction. For example, in the above embodiment where CMD 103 is permanently lost, an application on MCD 104 may be configured to allow at least a few transactions during the recovery period, e.g., transactions within a predetermined spending limit. However, when a transaction is requested, MCD 104 is configured to delay sending the fully authenticated request to the cryptocurrency network 106 for at least a predetermined time, allowing an authorized user to cancel the transaction before the request is sent to the network 106.

[0071] In some embodiments, CMS105 may require multiple social recovery contacts to provide a valid code rather than a single social recovery contact in order to provide additional security. Furthermore, some embodiments may use the aforementioned delay and notification process until the recovery process is complete. This may be used to allow an authorized user to cancel any fraudulent transactions that may be attempted during the recovery process. Thus, rather than relying on passwords and PINs for recovery, system 102 may, if necessary, also use passwords and PINs, but it may also allow authorized users to use social recovery contacts to help authenticate the user for key recovery.

[0072] It should be noted that System 102 allows an authorized user to list multiple social recovery contacts, and can permit recovery if the minimum number of social recovery contacts is less than the total number of social recovery contacts, and if the minimum number of social recovery contacts provides a valid code. For example, a user can define x social recovery contacts, and CMS 105 can provide its stored key for recovery if at least y of the social recovery contacts provide a valid code, and y is less than x. Therefore, recovery is permitted even if fewer than all of the social recovery contacts are available for verification.

[0073] Furthermore, the MCD104 application is configured to send one or more notifications of transaction requests to trusted addresses, such as telephone numbers or email addresses, established or updated by authorized users during registration. 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 a 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 MCD104 may be configured to submit the transaction request to the cryptocurrency network 106. Therefore, during the recovery process, the authorized user should be given a notification of the requested transaction and sufficient time to take steps to prevent the fraudulent transaction before it is sent to the cryptocurrency network 106 for processing.

[0074] Figure 8 is a flowchart illustrating the process of recovering a lost private key 108 using delay and notification, as described above. For example, the process can be used after a user has activated a new CMD103 following the loss of access to the previous CMD103.

[0075] First, as shown by block 802 in Figure 8, the owner of a user account 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 user account 118 via the cryptocurrency management app 113, and then the cryptocurrency management app 113 sending a CMD key exchange request from MCD 104 to CMS 105. Alternatively, in some embodiments, the user can log into user account 118 through an online web portal associated with CMS 105 and send a CMD key exchange request to CMS 105 through this web portal. In some embodiments, before CMS 105 acts on the CMD key exchange request, it may require the user to provide authentication information indicating a request from the owner of user account 118. For example, in some embodiments, CMS 105 may require the user to provide login authentication information (e.g., username and password) used to access user account 118. As another example, CMS105 may require the user to generate a valid signature for a hash of the data provided to the user by CMS105 using one of the private keys associated with the cryptocurrency address 107, such as private key 110. CMS105 can then verify the authenticity of the signature using the corresponding public key and 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 can receive and then verify the CMD key exchange request, as shown by block 803 in Figure 8. This may include, for example, the CMS verifying that the CMD key exchange request contains the necessary authentication information.

[0077] After receiving and verifying the CMD key exchange request, the CMS can start the CMD key exchange countdown in accordance with the user account's security policy, as shown by block 804 in Figure 8.

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

[0079] After the CMD key exchange countdown has finished without being canceled, as shown by block 806 in Figure 8, the CMS works with the MCD to authorize a transaction to transfer the funds associated with the cryptocurrency address to a new multi-signature cryptocurrency address protected by the private keys of the CMS, MCD, and the alternate CMD. For example, in some implementations, the MCD104 receives the alternate CMD's public key, generates a transaction to transfer the funds to a multi-signature cryptocurrency address corresponding to the existing public keys of the CMS105 and MCD104 and the new public key of the alternate CMD, signs it with its own private key, and then the alternate CMD and CMS105 sign with their corresponding private keys so that only the alternate CMD's private key 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 new public key of the alternative CMD and generate a transaction to transfer funds to the multi-signature cryptocurrency address corresponding to CMS105's new public key, MCD104 can sign the alternative CMD and sign it with its own new private key, and then the alternative CMD and CMS105 can sign with their corresponding private keys so that only the private key of the alternative CMD is replaced.

[0080] As shown by block 807 in Figure 8, the funds associated with the cryptocurrency address have been transferred to a new multi-signature cryptocurrency address.

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

[0082] In some implementations, authorization tokens can also be used in delayed and notification processing. For example, if a thief steals a user's MCD104 and attempts to pair it with a different CMD, the CMS105 can allow the MCD104 holding the most recently generated authorization token to initiate a delay and notify the process once. If the delayed and notification processing is canceled, or if the CMS105 sees that another MCD has a more recently generated authorization token, the CMS105 may require additional verification to initiate the delayed and notification processing. For example, the CMS105 may require a customer service agent to provide manual authorization only after the agent has received sufficient credentials from the user of the MCD making the request. By using authorization tokens in such a way, the CMS105 can automatically prevent the thief from initiating multiple delays and still be able to notify the request using the stolen MCD104.

[0083] In some embodiments, non-temporary computer-readable storage media containing instructions are also provided, which can be executed by the device in order to perform the methods described above. Common forms of non-temporary media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media having a pattern of holes, RAM, PROMs, and EPROMs, FLASH-EPROMs, or any other flash memory, NVRAMs, cache memory, registers, any other memory chips or cartridges, and networked versions thereof. The 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 herein may be implemented in hardware, software, or a combination of hardware and software. In some embodiments, functions described as being implemented in hardware may instead be implemented in software, or a combination of hardware and software. Similarly, in some embodiments, functions 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-temporary computer-readable medium, such as the computer-readable medium described above. When executed by a processor, such software may perform the functions of the device, module, or other functional unit that the software implements. The devices, modules, and other functional units described above may also be combined or further divided into a plurality of subunits.

[0085] In some places, standards are referenced, including standard ways of performing certain tasks. These standards are revised from time to time, and unless otherwise explicitly stated, references to standards in this disclosure refer to the most current published standards at the time of filing.

[0086] Spatially relative terms such as "under," "below," "lower," "over," and "upper" can be used herein to describe the relationship between one element or feature and other elements when the apparatus is in the correct hierarchical relationship.

[0087] When a feature is said to be “on top of” another feature, the feature may be directly on the other feature where no intervening feature exists, or indirectly on the other feature where an intervening feature exists. In contrast, when a feature is referred to as being “directly on top of” another feature, the feature is directly on the other feature where no intervening feature exists. When a feature is referred to as being “connected,” “attached,” or “combined” to another feature, it will also be understood that the feature may be directly connected, attached, or combined to the other feature in the absence of an intervening feature, or indirectly connected, attached, or combined to the other feature in the presence of an intervening feature. In contrast, when a feature is said to be “directly connected,” “directly attached,” or “directly combined” to another feature, the feature is directly connected, directly attached, or directly combined in the absence of an intervening feature.

[0088] The terms “about” and “approximately” generally mean an acceptable degree of error or variation in the measured quantity, taking into account the nature or precision of the measurement. A typical exemplary degree of error or variation is within 20%, preferably within 10%, more preferably within 5%, and even more preferably within 1% of a given value or range of values. Unless otherwise specified, the quantities described herein are approximate, and the terms “about” or “approximately” mean that they can be inferred unless explicitly stated.

[0089] Ordinal numbers or terms such as “first” and “second” are used solely to distinguish one entity or action from another entity or action, without requiring or implying any actual relationship or sequence between these entities or actions. Thus, a first feature or element may be referred to as a second feature or element, and similarly, a second feature or element may be referred to as a 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, and not to mean, that the item or item following any one of these words is an inclusive enumeration of such items or items, or is limited to only the enumerated items.

[0090] Where used herein, unless otherwise specified, the terms “or” and “at least one of” encompass all possible combinations unless they are impractical. For example, if it is stated that a component may include “A or B,” but this is not specifically stated or is impractical, the component may include “A,” “B,” or “A and B.” As a second example, if it is stated that a component may include “at least one of A, B, or C,” but this is not specifically stated or is impractical, the component may include “A,” “B,” “C,” “A and B,” “A and C,” “B and C,” or “A, B, and C.” This same configuration 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 unless the context clearly indicates otherwise.

[0092] Nothing in this disclosure that criticizes or condemns aspects of the prior art is intended to indicate that the claims exclude any of the criticized or condemned aspects of the prior art.

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

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

[0095] The aforementioned specification describes the embodiments with reference to numerous specific details, which may vary depending on the implementation. Specific adaptations and modifications of the described embodiments can be made. Other embodiments may be apparent to those skilled in the art from the discussion herein and the practice of the invention disclosed herein. This specification and each embodiment are intended to be illustrative only, and the true scope and spirit of the invention are set forth in the claims. Furthermore, the order of steps shown in the figures is for illustrative purposes only and is not intended to limit the steps to any particular order. Therefore, those skilled in the art will understand that these steps may be performed in different orders while carrying out the same method.

[0096] Embodiments of this disclosure can be implemented in accordance with at least the following sections.

[0097] Section 1: A cryptocurrency management system comprising: a mobile communication device (MCD) configured to generate a first authentication signature for use in authenticating transactions involving cryptocurrency multi-signature addresses of a cryptocurrency network based on a first private key stored by the MCD; a cloud server associated with the MCD configured to store an encrypted backup of the first private key, encrypted using an MCD backup encryption key provided to the Cryptocurrency Management Server (CMS); and a Cryptocurrency Management Server (CMS) configured to generate a second authentication signature for use in authenticating transactions involving the cryptocurrency multi-signature addresses of the cryptocurrency network based on a second private key stored by the CMS, wherein the second private key is associated with a first user account; the CMS of the cryptocurrency management system receives an MCD backup key request; and an MCD backup key recovery request is initiated in accordance with the security policy of the first user account for cryptocurrency multi-signature. A process for providing a first user with an MCD backup encryption key configured as follows, the process for verifying an MCD backup key request originating from the first user in response to receiving an MCD backup key request, the process for transmitting one or more sets of social recovery credentials to the first user, each of which sets of social recovery credentials is associated with a corresponding social recovery contact from a set of one or more social recovery contacts indicated by a security policy, the process for transmitting, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving, the process for receiving,One or more sets of social recovery credentials are associated with a corresponding social recovery contact from a set of one or more social recovery contacts, each receiving a corresponding social recovery confirmation message that verifies an MCD backup key request initiated by a first user, and each of the one or more social recovery confirmation messages, based on the set of credentials associated with the corresponding social recovery contact, receives one or more social recovery confirmation messages, and transmits an MCD backup cryptographic key to the first user in response to verifying the MCD backup key request initiated by the first user.

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

[0099] Section 3: The CMS is further configured to process one or more received social recovery verification messages, verify each received social verification message based on a set of social recovery credentials including the social recovery verification message, and to process that set of social recovery credentials corresponds to the set of social recovery credentials of the corresponding social recovery contact, and to send an MCD backup cryptographic key to a first user in response to verifying that each of the one or more received social verification messages is based on the respective set of social recovery credentials associated with the corresponding social recovery contact.

[0100] Section 4: A cryptocurrency management system as described in any of Sections 1 to 3, wherein the set of social recovery information transmitted by the CMS comprises at least a first number of sets of social recovery authentication information, and one or more social recovery verification messages received comprise one or more social recovery verification messages collectively based on at least a second number of sets of social recovery authentication information, 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 authentication information is associated with a different social recovery contact.

[0101] Section 5: A cryptocurrency management system as described in any of Sections 1-4, wherein the CMS and the first user account are associated with the first online platform, and the MCD backup key request is generated by using the first user account to access the first online platform.

[0102] Section 6: The cryptocurrency management system of Section 5, characterized in that the one or more social recovery verification messages are received from the first user, the one or more social recovery verification messages include information based on a password associated with logging into 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] Section 7: A cryptocurrency management system according to any one of Sections 1 to 6, further configured to receive a transaction request involving one or more cryptocurrency tokens associated with a cryptocurrency multi-signature address, wherein the transaction request comprises either a first or second authenticated signature; to generate an authenticated transaction using a third authenticated signature and either the first or second authenticated signature in response to receiving the transaction request; and to submit the authenticated transaction to a cryptocurrency network.

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

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

[0106] Section 10: The cryptocurrency management system described in Section 9, wherein the transaction policy requires that the initiated transaction be less than a certain amount.

[0107] Section 11: A method for managing cryptocurrency, comprising generating a first authentication signature for use in authenticating a transaction involving a cryptocurrency multi-signature address of a cryptocurrency network, based on a first secret key stored by a cryptocurrency management server (CMS), wherein the first secret key is associated with a first user account of a first user on the CMS, and receiving a mobile communications device (MCD) backup key request configured to initiate a process for providing the first user with an MCD backup encryption key in accordance with the security policy of the first user account for the cryptocurrency multi-signature address, wherein the second secret key is stored by an MCD configured to use the second secret key to generate a second authentication signature for use in authenticating a transaction involving the cryptocurrency multi-signature address of the cryptocurrency network, and the MCD stores an encrypted copy of the second secret key on a cloud server associated with the MCD, the 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), the third private key is configured to use the third private key to generate a third authentication signature for use when authenticating a transaction with the Cryptocurrency multi-signature address of the Cryptocurrency Network, and in response to receiving the MCD backup key request, the CMD backup key request originated by the first user is verified, and one or more sets of social recovery credentials are sent 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 the corresponding social recovery contacts are received one or more social recovery verification messages indicating that each of them acknowledges the MCD backup key request originated by the first user.A method comprising: sending each of the one or more social recovery verification messages to a collection of one or more social recovery credentials indicated by a security policy, where each of the one or more sets of corresponding social recovery credentials is associated with the corresponding social recovery contact from a collection of one or more social recovery contacts; and receiving one or more social recovery verification messages, each indicating a corresponding social recovery contact, 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, and in response to receiving one or more social recovery verification messages and verifying an MCD backup key request originating from the first user, the method includes sending an MCD backup cryptographic key to the first user.

[0108] Section 12: The method of Section 11, further comprising the MCD retrieving an encrypted backup of the second private key from a cloud server associated with the MCD, and the MCD recovering 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] Section 13: The method according to any one of Sections 11-12, wherein sending a set of social recovery credentials comprises sending at least a first number of sets of social recovery credentials, and receiving one or more social recovery verification messages comprises receiving one or more social recovery verification messages based collectively 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.

[0110] Clause 14: The method of any one of Clauses 11 to 13, further comprising processing 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 for the corresponding social recovery contact, and transmitting an MCD backup cryptographic key to a first user in response to verifying that each of the one or more received social verification messages is based on the respective set of social recovery credentials associated with the corresponding social recovery contact.

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

[0112] Section 16: The method of Section 15, wherein one or more social recovery verification messages are received from a first user, and each of the one or more received social recovery verification messages includes password-based information relating to logging into the first user account, and the method further comprises 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 extracted from the password associated with the first user account.

[0113] Section 17: A method according to any of Sections 11 to 16, further comprising receiving a transaction request, which includes one or more cryptocurrency tokens associated with the cryptocurrency multi-signature address, wherein the transaction request includes either the second authentication signature or the third authentication signature, and the transaction request includes authentication information indicating that the transaction request is from the first user; 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; and presenting the authenticated transaction to the cryptocurrency network.

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

[0115] Section 19: When executed by at least one processor, at least one processor is configured to generate a first authentication signature for use in authenticating a 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, the MCD backup key request being configured to initiate a process to provide the first user with an MCD backup encryption key in accordance with the 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 a second authentication signature for use in authenticating a transaction involving the cryptocurrency multi-signature address of the cryptocurrency network using the second private key, the MCD being 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 encryption key, The third private key is encrypted using the third private key, the third private key is stored by the Cryptocurrency Management Device (CMD), the third private key is configured to generate a third authentication signature for use in authenticating transactions with cryptocurrency multi-signature addresses of the cryptocurrency network, and in response to receiving an MCD backup key request, verifying an MCD backup key request originating from the first user is to send one or more sets of social recovery credentials to the first user, each of which sets of social recovery credentials is associated with a corresponding social recovery contact from a collection of one or more social recovery contacts indicated by the security policy, and based on the set of corresponding social recovery contacts originating from the first user,A non-temporary computer-readable medium comprising instructions for managing cryptocurrency by transmitting one or more sets of social recovery credentials to one or more sets of social recovery credentials as indicated by a security policy, each of which sets of social recovery credentials is associated with a corresponding social recovery contact from a collection of one or more social recovery contacts; and receiving one or more social recovery verification messages, each of which indicates that a corresponding social recovery contact acknowledges an MCD backup key request originated from a first user, each of which social recovery verification messages is based on a set of credentials associated with a corresponding social recovery contact; and receiving one or more social recovery verification messages from a first user.

[0116] Section 20: The non-temporary computer-readable medium as described in Section 19, wherein the instruction causes the at least one processor to manage the cryptocurrency by having the MCD retrieve the encrypted backup of the second private key from the cloud server associated with the MCD, and by having the MCD recover the second private key, and 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.

[0117] Section 21: A non-temporary computer-readable medium according to any one of Sections 19 to 20, wherein the instruction further causes the at least one processor to manage the cryptocurrency by sending the MCD backup crypto key to the first user in response to processing the one or more received social recovery verification messages for each received social recovery verification message based on a set of social recovery authentication information of the corresponding social recovery contact, and verifying that each of the one or more received social verification messages is based on the respective set of social recovery authentication information associated with the corresponding social recovery contact.

[0118] Section 22: A non-temporary computer-readable medium as described in any of Sections 19 to 21, wherein transmitting the set of social recovery authentication information comprises transmitting at least a first number of sets of social recovery authentication information, and receiving the one or more social recovery verification messages comprises receiving one or more social recovery verification messages based collectively on at least a second number of sets of social recovery authentication information, wherein the second number is less than or equal to the first number, and each of the at least second number of sets of social recovery authentication information is associated with a different social recovery contact.

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

[0120] Section 24: A non-temporary computer-readable medium as described in Section 23, which receives one or more social recovery verification messages from a first user, each of the received social recovery verification messages contains password-based information relating to logging into the first user account, and further comprises processing the received 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] Section 25: The non-temporary computer-readable medium as described in any one of Sections 19 to 24, wherein the instruction further causes the at least one processor to manage a cryptocurrency by receiving a transaction request, which includes one or more cryptocurrency tokens associated with a cryptocurrency multi-signature address, the transaction request including either the second or third authentication signature, and the transaction request including authentication information indicating that the transaction request is the transaction request 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 or third authentication signature in response to verifying the authentication information; and presenting the authenticated transaction to the cryptocurrency network.

[0122] Section 26: The non-temporary computer-readable medium described in Section 25, wherein the instruction further causes the at least one processor to manage the cryptocurrency by processing the transaction request to determine whether the transaction request conforms to the transaction policy of the first user account for the cryptocurrency multi-signature address, and, in accordance with the determination that the transaction request conforms to the transaction policy, by generating the authenticated transaction.

Claims

1. It is a cryptocurrency management system, Mobile communication devices (MCDs) (104, 113), Based on the first private key (110) stored by the MCD, a first authentication signature is generated for use in authenticating a transaction involving a cryptocurrency multi-signature address of a cryptocurrency network. The first copy of the private key is encrypted using the MCD backup encryption key provided to the cryptocurrency management server (CMS) (105), The cloud server associated with the MCD stores an encrypted copy of the first secret key (117). An MCD configured as follows, The cryptocurrency management server (CMS) is as follows: The method involves generating a second authentication signature for use in authenticating a transaction involving a cryptocurrency multi-signature address of the cryptocurrency network, based on a second private key (115) stored by the CMS (105), wherein the second private key (115) is associated with a first user account (118) of a first user on the CMS (105), and generating the signature. Receiving an MCD backup key request, the MCD backup key request is configured to initiate a process for providing the MCD backup cryptographic key to the first user in accordance with the security policy (116) of the first user account for the cryptocurrency multi-signature address, In response to receiving the aforementioned MCD backup key request, the MCD backup key request originated from the first user is verified, and the process involves either of the following series of steps (1) and (2): （１） Sending one or more sets of social recovery credentials to the first user, wherein each of the one or more sets of social recovery credentials is associated with a corresponding social recovery contact from a set of one or more social recovery contacts indicated by the security policy, and Receiving one or more social recovery verification messages, each indicating that a corresponding social recovery contact has acknowledged the MCD backup key request initiated by the first user, wherein each of the one or more social recovery verification messages is received based on the set of social recovery authentication information received from and associated with the corresponding social recovery contact. (2) Transmitting one or more sets of social recovery authentication information to one or more sets of social recovery contacts indicated by the security policy, wherein each of the one or more sets of social recovery authentication information is associated with a corresponding social recovery contact from the set of one or more social recovery contacts, and The corresponding social recovery contact receives one or more social recovery verification messages indicating that it acknowledges the MCD backup key request originated from the first user, and each of the one or more social recovery verification messages is received based on the set of authentication information associated with the corresponding social recovery contact. Verified by either of the following methods, Upon receiving one or more social recovery verification messages and verifying the MCD backup key request initiated by the first user, the MCD backup encryption key (117) is transmitted to the first user. A CMS configured in such a way, A cryptocurrency management system, including...

2. The system according to claim 1, wherein the MCD further From the cloud server associated with the MCD, retrieve the encrypted copy of the first secret key. The first private key is recovered by decrypting the extracted encrypted copy of the first private key using the MCD backup encryption key transmitted to the first user by the CMS. A cryptocurrency management system that is further composed of these components.

3. The cryptocurrency management system according to claim 1, wherein the CMS further, The system processes one or more received social verification messages to verify that each received social verification message is based on a set of social recovery credentials that includes a social recovery verification message corresponding to a set of social recovery credentials for a corresponding social recovery contact. To the first user, in response to verifying that each of the one or more received social verification messages is based on the respective set of social recovery authentication information associated with the corresponding social recovery contact, the MCD backup encryption key is transmitted. A cryptocurrency management system configured in such a way.

4. A 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 authentication information. The one or more social recovery verification messages received include one or more social recovery verification messages collectively based on at least two sets of social recovery authentication information, The second number is less than or equal to the first number, A cryptocurrency management system in which each of the aforementioned two sets of social recovery authentication information is associated with a different social recovery contact.

5. A cryptocurrency management system according to claim 1, The CMS and the first user account are associated with the first online platform. The MCD backup key request is generated by accessing the first online platform using the first user account. The one or more social recovery verification messages mentioned above are received from the first user. Each of the one or more received social recovery verification messages includes information based on the password associated with logging into the first user account. The CMS is further configured to process one or more received social recovery verification messages in order to verify that each received social verification message is based on the information extracted from the password associated with the first user account, a cryptocurrency management system.

6. A cryptocurrency management system according to any one of claims 1 to 5, wherein the CMS further A transaction request comprising one or more cryptocurrency tokens associated with the cryptocurrency multi-signature address, comprising either the first authentication signature or the second authentication signature, upon receiving the transaction request, Upon receiving the aforementioned transaction request, a transaction authenticated using a third authentication signature and either the first authentication signature or the second authentication signature is generated. A cryptocurrency management system configured to present the authenticated transaction to the cryptocurrency network.

7. A cryptocurrency management system according to claim 6, The transaction request includes authentication information indicating that the transaction request is from the first user. The aforementioned CMS further, To verify the authentication information, the transaction request is processed. The authenticated transaction is generated in accordance with the verification of the authentication information. A cryptocurrency management system configured in such a way.

8. The cryptocurrency management system according to claim 7, wherein the CMS further, The transaction request is processed in order to determine whether the transaction request conforms to the transaction policy of the first user account for the cryptocurrency multi-signature address. In response to determining that the transaction request conforms to the transaction policy, the authenticated transaction is generated. A cryptocurrency management system configured in such a way.

9. A method for managing cryptocurrency, In a cryptocurrency management server (CMS) (105), a first authentication signature is generated for use in an authentication transaction involving a cryptocurrency multi-signature address of a cryptocurrency network, based on a first private key (115) stored by the CMS (105), wherein the first private key (115) is associated with a first user account (118) of a first user on the CMS (105). The CMS (105) receives an encrypted copy of a second private key (117) encrypted using a mobile communication device (MCD) backup encryption key provided to the CMS (105), wherein the second private key (110) is configured to be stored and used by the MCD (104) to generate a second authentication signature used in the authentication of a transaction involving the cryptocurrency multi-signature address of the cryptocurrency network. The CMS (105) receives a mobile communication device (MCD) (104) backup key request, the MCD backup key request is configured to initiate a process in the CMS (105) to provide the first user with an MCD backup encryption key (117) in accordance with the security policy (116) of the first user account (118) for the cryptocurrency multi-signature address. In the CMS (105), upon receiving the MCD backup key request, the MCD backup key request originating from the first user is verified, and the following series of steps (1) and (2) are performed: (1) Sending one or more sets of social recovery authentication information to the first user, wherein each of the one or more sets of social recovery authentication information is associated with a corresponding social recovery contact from a set of one or more social recovery contacts indicated by the security policy, and Receiving one or more social recovery verification messages, wherein each of the one or more social recovery verification messages indicating a corresponding social recovery contact confirms the MCD backup key request originated from the first user, and 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 authentication information associated with the corresponding social recovery contact. (2) Transmitting one or more sets of social recovery authentication information to one or more sets of social recovery contacts indicated by the security policy, wherein each of the one or more sets of social recovery authentication information is associated with a corresponding social recovery contact from the set of one or more social recovery contacts, and Receiving one or more social recovery verification messages, wherein each of the one or more social recovery verification messages indicating a corresponding social recovery contact confirms the MCD backup key request originated from the first user, and each of the one or more social recovery verification messages is received based on a set of authentication information associated with the corresponding social recovery contact. Verification can be done by either of the following methods, Upon receiving one or more social recovery verification messages and verifying the MCD backup key request initiated by the first user, the MCD backup encryption key is sent to the first user. Methods that include...

10. The method according to claim 9, The MCD retrieves the encrypted copy of the second secret key from the cloud server associated with the MCD, The MCD recovers the second private key, wherein the MCD recovers the second private key by decrypting the extracted encrypted copy of the second private key using the MCD backup encryption key transmitted to the first user by the CMS. Methods that further include this.

11. The method according to claim 9, Transmitting the aforementioned set of social recovery credentials includes transmitting at least one set of social recovery credentials. Receiving one or more social recovery verification messages includes receiving one or more social recovery verification messages that are collectively based on at least two sets of social recovery authentication information. The second number is less than or equal to the first number, A method wherein each of the at least two sets of social recovery authentication information is associated with a different social recovery contact.

12. The method according to claim 9, Processing one or more received social verification messages to verify that each received social verification message is based on the set of social recovery authentication information of the corresponding social recovery contact, In response to verifying that each of the one or more received social verification messages is based on a separate set of social recovery authentication information associated with the corresponding social recovery contact, the MCD backup encryption key is sent to the first user. Methods that further include this.

13. The method according to claim 9, The first user account is associated with the first online platform, A method by which the MCD backup key request is generated by accessing the first online platform using the first user account.

14. The method according to claim 13, The one or more social recovery verification messages mentioned above are received from the first user. Each of the one or more received social recovery verification messages includes information based on the password associated with logging into the first user account. The method further comprises processing the one or more received social recovery verification messages to verify that each received social verification message is based on information extracted from the password associated with the first user account.

15. A method according to any one of claims 9 to 14, Receiving a transaction request involving one or more cryptocurrency tokens associated with the cryptocurrency multi-signature address, which is generated from a third private key stored by a cryptocurrency management device (CMD) used to authenticate a transaction involving the cryptocurrency multi-signature address of the cryptocurrency network, 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 To process the transaction request in order to verify the authentication information, In response to verifying the authentication information, a transaction authenticated using the first authentication signature and either the second authentication signature or the third authentication signature is generated. Presenting the authenticated transaction to the cryptocurrency network, Methods that further include this.

Images