Risk mitigation for a cryptographic asset custodial system using data points from multiple mobile devices

Abstract

Methods, systems, and apparatus for risk mitigation in crypto asset custody systems include: transmitting an endorsement request for a crypto asset transaction to a user device, the endorsement request being configured to prompt the user device to endorse the crypto asset transaction; collecting multiple data points from a mobile device associated with the user, these data points representing the user's identity; receiving a cryptographic endorsement of the crypto asset transaction from the user device; and generating a graphical visualization based on the data points, including a risk metric representing the risk of accepting the cryptographic endorsement from the user device. Generating the graphical visualization includes determining whether the multiple data points match expected values.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefits of U.S. Patent Application No. 16 / 577,361, filed September 20, 2019, and U.S. Provisional Application No. 62 / 889,381, filed August 20, 2019. Technical Field

[0003] This manual typically addresses risk mitigation for crypto asset custody systems. Background Technology

[0004] In recent years, cryptocurrencies such as Ethereum have gained popularity and value, and many expect this to continue. The variety of cryptocurrency-based transactions is increasing daily, and it's conceivable that new types of crypto-assets—that is, crypto assets that are not necessarily currencies—may emerge in the future.

[0005] As the use of crypto assets increases, there is a need for trusted custodian systems that can securely store large amounts of crypto assets and control access to those assets. In fact, U.S. securities regulations require certain entities holding more than a certain amount of funds on behalf of another party (e.g., $150 million) to use custodians. Hardware wallets and other forms of "cold storage" are sometimes used to store cryptocurrencies; however, these devices restrict access only to the device's owner, making them unsuitable for many business purposes where numerous individuals may need access to crypto funds or other crypto assets. Summary of the Invention

[0006] This specification describes risk mitigation for a crypto asset custody system (sometimes referred to as "CCS"). Methods, systems, and apparatus for risk mitigation in a crypto asset custody system include: a server computer configured to transmit an endorsement request for a crypto asset transaction to be conducted by the server computer on a blockchain. The endorsement request may be transmitted to a user device associated with a user of the crypto asset custody system. The endorsement request may be configured to prompt the user device to endorse the crypto asset transaction. The server computer may receive multiple data points collected from one or more mobile devices communicatively coupled to and associated with the user device. The data points may represent the user's identity. A risk analysis module is communicatively coupled to the server computer. The risk analysis module may generate a graphical visualization of a risk metric based on the data points on a risk assessment dashboard. The risk metric represents the risk of accepting the endorsement of the crypto asset transaction from the user device.

[0007] These and other aspects, features, and implementations may be represented as methods, apparatus, systems, components, program products, parts, or steps for performing the function, and may be represented in other ways.

[0008] These and other aspects, features, and implementations will become apparent from the following description, including the claims. Attached Figure Description

[0009] Figure 1 This shows a sample block diagram of a crypto asset custody system.

[0010] Figure 2A This is a schematic diagram illustrating an example of a deposit processing flow utilizing a crypto asset custody system.

[0011] Figure 2B This is a flowchart illustrating an example of the storage processing flow.

[0012] Figure 3A This is a schematic diagram illustrating an example of a withdrawal process using a crypto asset custody system.

[0013] Figure 3B This is a flowchart illustrating an example of the extraction process.

[0014] Figure 4 This is a flowchart illustrating an example of the processing performed by a hardware security module in conjunction with a requested operation.

[0015] Figure 5 This is a flowchart illustrating an example of a process for endorsing a requested transaction using an offline user device.

[0016] Figure 6 This diagram illustrates an example block diagram of a crypto asset custody system that uses data points from mobile devices for risk mitigation.

[0017] Figure 7 This shows the trend of data points collected from mobile devices.

[0018] Figure 8 This illustrates risk mitigation procedures used in crypto asset custody systems.

[0019] Figure 9 This is a high-level block diagram illustrating an example of a hardware architecture that can be used to implement part or all of a processing system for a crypto asset custody system or user device. Detailed Implementation

[0020] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of the disclosed embodiments. However, it will be apparent that these embodiments may be practiced without these specific details.

[0021] In the accompanying drawings, for ease of illustration, a specific arrangement or order of schematic elements (such as elements representing devices, modules, instruction blocks, and data elements) is shown. However, those skilled in the art will understand that the specific order or arrangement of the schematic elements in the drawings is not intended to imply a specific order or sequence of processes or separation of procedures. Furthermore, the inclusion of schematic elements in the drawings is not intended to imply that such elements are required in all embodiments, nor does it imply that features represented by such elements may be excluded from other elements or may not be combined with other elements in some embodiments.

[0022] Furthermore, in the accompanying drawings, when connecting elements (such as solid or dashed lines or arrows) are used to illustrate connections, relationships, or associations between two or more other schematic elements, the absence of any such connecting element does not imply that connections, relationships, or associations cannot exist. In other words, some connections, relationships, or associations between elements are not shown in the drawings so as not to obscure the content of this disclosure. Additionally, for ease of illustration, a single connecting element may be used to represent multiple connections, relationships, or associations between elements. For example, in the case where a connecting element represents communication of signals, data, or instructions, those skilled in the art will understand that such an element represents one or more signal paths (e.g., a bus) that may be necessary to influence the communication.

[0023] Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding of the various embodiments described. However, it will be apparent to those skilled in the art that the various embodiments described may be practiced without these specific details.

[0024] Several features are described below, each of which can be used independently of the others or in any combination with other features. However, any single feature may not solve any of the problems discussed above, or may only solve one of the problems discussed above. Some of the problems discussed above may not be fully solved by any of the features described herein. Although headings are provided, information relating to a particular heading but not found in the section bearing that heading may also be found in other sections of this specification.

[0025] Figure 1A sample block diagram of a crypto asset custody system 100 is shown. The crypto asset custody system 100 is a computer-implemented system for maintaining the custody of cryptocurrencies and / or other crypto assets and controlling access to cryptocurrencies and / or other crypto assets. The crypto asset custody system 100 may be owned and / or operated by a commercial enterprise (referred to herein as a crypto asset custody institution). The crypto asset custody system 100 includes multiple layers of security to enable the secure maintenance of a large number of crypto assets. In some embodiments, the crypto asset custody system 100 includes a combination of biometric-based multi-user authentication, transaction risk analysis, and the use of a hardware security module 105 to provide authentication / verification functions and secure storage of private keys for crypto assets. Furthermore, two or more different biometric authentication technologies may be applied to any given transaction request. As used herein, the term "hardware security module" refers to a dedicated physical computing device used to protect and manage digital keys used for authentication and to provide cryptographic processing functions. The hardware security module 105 may be embodied as an insert card or an external device directly attached to a computer.

[0026] In some embodiments, when user device 108 requests a transaction involving crypto assets (such as the withdrawal or transfer of cryptocurrency funds), crypto asset custody system 100 causes an endorsement request message to be sent to each of a plurality of user devices 108, wherein each user device is associated with a different user who has been defined as a qualified member of a predetermined number (quorum) for a transaction involving the crypto asset (in other embodiments, multiple users may share the same user device 108). The endorsement request message is configured to prompt each receiving user device 108 to provide a cryptographic endorsement of the requested transaction by its endorser / user. In this context, an endorsement is the endorser / user's approval or rejection of the operation. When an endorser / user who receives such a prompt endorses the transaction on his or her user device 108 (e.g., a smartphone, tablet, or laptop), the user device 108 signs the cryptographic endorsement with the user's private key and transmits the signed endorsement to crypto asset custody system 100. The private key is stored in a securely designated address space 114 within user device 108. The secure designated address space 114 in each user device 108 is used to store the private key of the corresponding user and generate the digital signature of the user.

[0027] Hardware security module 105 determines whether a predetermined number of users, based on a policy, have endorsed (approved) a requested action, such as the withdrawal or transfer of cryptocurrency funds. Upon receiving cryptographic endorsements from users, hardware security module 105 generates a signature for each user using the private key from the public-private key pair and verifies the signature using the public key. In one implementation, hardware security module 105 only allows itself to access or derive the private key for that specific crypto asset (e.g., for specific deposits into a cryptocurrency fund) and uses that private key to sign the transaction as authorization for the transaction to proceed, after determining that a predetermined number of users have effectively endorsed the requested action based on the policy.

[0028] A client key can be used to access or derive the private key (sometimes referred to as an "encryption key") of a specific cryptographic asset, and the client key can be derived from an encrypted client key stored on one or more user devices for use by the client's authorized representative. The encrypted client key can be transmitted to hardware security module 105, and the hardware security module can derive the client key by decrypting it using a hardware-based encryption key stored in the secure storage of hardware security module 105. The hardware-based encryption key within the secure storage 107 of hardware security module 105 is stored only within hardware security module 105, and therefore cannot be read by any entity outside of hardware security module 105. Transaction approval may include, for example, transmitting the transaction to a known blockchain network. In some embodiments, the hardware security module 105 approves the transaction only after the requested transaction has undergone a risk review, which may be partially or fully automated. The systems and techniques described herein can also be used for the secure custody of other types of digital assets besides cryptographic assets.

[0029] Now for reference Figure 1This diagram illustrates a high-level block diagram of a crypto-asset custody system 100. In the illustrated embodiment, the crypto-asset custody system 100 includes a server computer 102, a relay server 103, a risk analysis module 104, a hardware security module 105, and a data storage facility 106. The data storage facility 106 may include one or more databases, which may be or include relational databases or any other type of organization for storing data in an organized manner, wherein the data may be structured and / or unstructured data. The hardware security module 105 also includes its own internal secure storage facility 107. Note that multiple instances of each of the above components may exist in the crypto-asset custody system 100, although only one instance of each component is shown for simplicity. One or more user devices 108 (also referred to as “clients”) may communicate with the crypto-asset custody system 100 via a public computer network 109 such as the Internet. Each user device 108 may be any of, for example, a smartphone, tablet computer, laptop computer, and desktop computer. Each user device 108 may include a secure designated address space 114, such as an iOS-based secure designated address space, for storing the private key of the corresponding user and generating the user's digital signature. In at least some embodiments, each user device 108 is associated with a different user, and such embodiments are used in the following description for ease of illustration. However, it should be noted that embodiments may have multiple users sharing the same user device 108.

[0030] In some embodiments, relay server 103 acts as a bridge across a physical air gap to isolate hardware security module 105 from public computer network 109. In other embodiments, relay server 103 acts as a virtual air gap to isolate hardware security module 105 from public computer network 109. Relay server 104 and hardware security module 105 operate within secure zone 110. Hardware security module 105 can reside physically within a physically secure data center that cannot directly access any external networks. Messages between hardware security module 105 and server computer 102 are routed to relay server 103 in secure zone 110 over a half-duplex connection. Relay server 103 disconnects itself from the secure network when communicating with server computer 102 and from all external networks when communicating with hardware security module 105, making it impossible to establish interactive sessions with these devices from the outside. Relay server 103 provides "air gap" security for critical infrastructure.

[0031] In some embodiments, the crypto asset custody system 100 may also access at least one blockchain network 111 corresponding to the crypto assets for which the crypto asset custody system 100 has custody rights. Access to the blockchain network 111 may be via a public computer network 109 (e.g., the Internet).

[0032] In some embodiments, each transaction submitted by a client of the crypto asset custody system 100 will undergo a risk analysis module 104, which may be partially or fully automated. For example, in some embodiments of the crypto asset custody system 100, automated risk analysis software may determine whether a proposed transaction is acceptable. The risk analysis agent or software may follow strategies set on individual vaults and may examine any risk signals among various risk signals (e.g., transaction amount, number of users authorizing the transaction, location of the request and approval of the transaction (one or more), destination address) to calculate a final risk metric that may lead to approval of the transaction or a request for more information.

[0033] Figure 2A This is a schematic diagram illustrating an example of the deposit processing flow using the crypto asset custody system 100. Figure 2B This is a flowchart illustrating an example of a deposit processing flow. In some embodiments, the deposit is initiated by a client via the Internet through a software application (hence referred to as the "Crypto Asset Custody System Application") executed on the client's user device 108. In some embodiments, the deposit operation is initiated using a web dashboard. Such initiation of a deposit request may require cryptographic endorsement of the Crypto Asset Custody System Application. In some embodiments, the initiation of a deposit request does not require cryptographic endorsement.

[0034] Deposits can be initiated by a client selecting a crypto asset type and requesting a deposit amount within the crypto asset custody system application. Once initiated, the request for the blockchain deposit address is sent to server computer 102, which receives the request (step 201) and forwards it via relay server 103 (step 202) to hardware security module 105 (as described above, hardware security module 105 is isolated from the Internet via relay server 103). Hardware security module 105 generates (step 203) a new public-private key pair 221 uniquely corresponding to the deposit, i.e., the requested blockchain address. In some embodiments, hardware security module 105 uses the private key of the relevant organization and a key derivation function (KDF) to generate a new key pair for the blockchain address. As discussed further below, in this context, "organization" refers to a data structure corresponding to a specific client. In one implementation, the private key in the newly generated key pair cannot be extracted from hardware security module 105 but can be securely backed up in an encrypted file. In this implementation, the key generation within the hardware security module 105 ensures that the private key 221 exists only within the hardware security module 105, is not available anywhere else in the world, and cannot be accessed by any entity outside the hardware security module 105.

[0035] Next, the hardware security module 105 generates (step 204) the blockchain address to be used based on the public key in the newly created key pair. A blockchain-specific transformation of the public key of the blockchain address can be used. The hardware security module 105 signs the blockchain address with the organization's private key (step 205) and returns the signed blockchain address to the server computer 102. The server computer 102 causes (step 206) the signed blockchain address 222 to be sent to the client's user device 108, so that the user device 108 presents the address to the client in an easy-to-use and shareable format (e.g., as a QR code) in the crypto asset custody system application on the user device 108 for use as a destination address in blockchain transactions. The crypto asset custody system application on the user device 108 verifies (step 207) the signature of the address before presenting it to the client.

[0036] The client's user device 108 uses the organization's public key (which was previously received from and locally stored in the crypto asset custody system 100) to verify the authenticity of the blockchain address received by the user device 108 from the crypto asset custody system 100. The client initiates (step 208) a transaction to deposit crypto assets into the crypto asset custody system 100. This transaction can be initiated from an exchange, from the client's personal wallet, or from another crypto asset store. The crypto assets appear in the crypto asset custody system 100 without confirmation.

[0037] The deposited addresses are stored together with other addresses belonging to the client within the crypto asset custody system 100 in a collection (referred to as the client's "vault"). In this context, a vault is a data entity containing crypto assets and a strategy graph containing one or more policies for managing the deposits and withdrawals of these crypto assets and related blockchain governance actions. Governance actions, for example, can include delegation, staking, and voting. Policies can manage participation in transactions related to crypto assets. Crypto assets are represented as slots within a vault that can hold a certain amount of a crypto asset type (e.g., Ethereum). Once custodied and stored using the crypto asset custody system 100, the crypto assets are entirely under the control of the crypto asset custody system 100.

[0038] Server computer 102 determines whether the client has confirmed the transaction within the defined time period (steps 209, 210). Once the deposit transaction is confirmed by the client and verified on the blockchain, server computer 102 notifies the client of this (step 211), and the crypto asset is considered to be held in custody by the crypto asset custody system 100. If no confirmation is received within the defined time period, server computer 102 notifies the client of an error in the transaction (step 212).

[0039] Figure 3A This is a schematic diagram illustrating an example of a withdrawal process using a crypto asset custody system 100. Figure 3B This is a flowchart illustrating an example of the retrieval process. Figure 3A and Figure 3B This illustrates an example of processing the withdrawal of a certain amount of previously deposited crypto assets (such as cryptocurrencies). A withdrawal can be initiated from a crypto asset custody system application on user device 108A by selecting the specific crypto assets and amount to be withdrawn. Once initiated, the authorizing party is notified of the withdrawal request. In one implementation, a specified number of authorized clients or users are required to individually authorize the withdrawal request on their mobile devices 108A and 108B. In some embodiments, one or more “requested” clients or users are required to authorize the withdrawal request. These one or more “requested” clients or users can be part of a specified number. In some embodiments, the defined specified number must be met, and all “requested” users must authorize the transaction. In some embodiments, condition definitions for “requested” users can be implemented. For example, “Joe Doe is required if the USD valuation is higher than $1 million or if the transaction amount exceeds 50% of the crypto asset holdings at a given time.” In other embodiments, approval or conditions for additional requirements are configured for the “policy” to be met.

[0040] During this process, authorized users are required to review and approve transactions, with each user's approval potentially being biometrically authenticated (e.g., fingerprint, facial recognition, and / or voice recognition). In some embodiments, each request is sent to a risk analysis module 104 for scrutiny and authorization as legitimate before the withdrawal can successfully proceed to the next stage. A hardware security module 105 can verify that a transaction has been authorized by a defined, predetermined number of users (e.g., a majority, 25%, or 33%) and approved by the risk review module 104. For example, for a given corporate client with five different employees who need the ability to transfer funds, an appropriate predetermined number configuration might require verified approval from a group consisting of three of these five employees to move any funds. Once the hardware security module 105 has verified compliance with a policy graph that includes any predetermined number requirements, it authorizes the requested transaction (e.g., the requested withdrawal) by signing it with the account holder's private crypto-asset-specific key. The server computer 102 submits the signed crypto-asset movement transaction to the blockchain 111.

[0041] exist Figure 3B The following further illustrates an example of the withdrawal process. Server computer 102 initially receives (step 301) a withdrawal request 331 from the client. Server computer 102 examines (step 302) the approval policy for the crypto assets being traded (as shown in the crypto asset vault) to determine which individuals' authorizations (endorsements) are available to satisfy the prescribed quantity required to approve the withdrawal. Server computer 102 sends (step 303) endorsement requests to the mobile devices 108A, 108B of these individuals (these mobile devices have previously been registered in the crypto asset custody system 100). In response to these requests, one or more cryptographic endorsements may be received from the users' mobile devices 108A, 108B, wherein, as further described below, these cryptographic endorsements are locally signed by the users' respective private keys securely stored in their respective mobile devices and are authenticated by one or more biometric authentication technologies. Therefore, as specified in the policy for crypto assets, server computer 102 determines (step 304) whether the prescribed number of authorizations has been received within the timeout period and whether the corresponding authorizing party has been authenticated. If the result is "yes", then server computer 102 will pass transaction request 331 (step 305) to risk analysis module 104. Otherwise, server computer will send a transaction rejection notification (step 310) to at least the user who requested the transaction (and possibly to all other users identified in the policy for crypto assets).

[0042] Risk analysis module 104 performs risk analysis, which may be fully or partially automated as described above (step 306). If the transaction passes the risk analysis (step 306), the control flow is passed to hardware security module 105, which verifies (step 308) whether the prescribed quantity requirement is met by performing the same or similar judgment as in step 304, as does risk analysis module 104 (step 306) (further described below). If hardware security module 105 verifies that the prescribed quantity is met, it signs the withdrawal transaction using the private key of the blockchain address. Server computer 102 submits the transaction to blockchain 111 to execute the withdrawal (step 309). Otherwise, hardware security module 105 signals a failure to server computer 102, which, in response, sends a transaction rejection notification (step 310) at least to the user who requested the transaction (and possibly to all other users identified in the policy for crypto assets).

[0043] As described above, when a user endorses a transaction request, the user can undergo one or more forms of authentication by their mobile device and / or the crypto asset custody system 100 to determine that the user is the intended person to take the action. These forms of authentication may include one or more biometric authentication technologies, such as fingerprint verification, voiceprint verification, voice recognition, facial recognition, and / or gesture recognition. The user's mobile device (e.g., a smartphone) may perform one or more of these authentication technologies.

[0044] Additionally or optionally, users may be required to upload videos taken by their mobile devices to the crypto asset custody system 100, where the user's identity can be verified from the video, for example, by: identifying the user's face in the video against an image of a known face (e.g., a previous video of the user); identifying the user's voice in the video against a trained voice profile of the user; requiring the user to say specific words or take specific actions in the video based on a transaction (see further discussion below); requiring the user to assume a previously specified posture or a painful posture when in pain; requiring the user to identify the expected room in the video; and / or performing any other action that is considered to increase the level of confidence in who the user is claiming to be.

[0045] When deemed necessary, a user can be required to complete a challenge to verify that he or she is indeed the person authorized to take action on the transaction. These challenges can be generated deterministically based on the context of the transaction. For example, based on key information in the transaction such as ID, amount, or destination, the crypto asset custody system 100 can generate random numbers that can be used to select several (e.g., three to five) words from a known set of words. The crypto asset custody system 100 can present these words to the user and have the user say them in a video recorded by the user's mobile device, which is then transmitted to the crypto asset custody system 100. During transaction review, the reviewing body can independently generate the expected words based on the transaction data and verify that the user said these words. The video can also undergo facial and / or voice recognition. By performing this deterministic challenge generation, attackers can prevent forging transactions by recording and reusing previously transmitted authentication videos from the user.

[0046] Figure 4 This is a flowchart illustrating an example of the processing performed by the hardware security module 105 in conjunction with the requested operation. The primary function of the hardware security module 105 is to verify the validity of the operation. The hardware security module 105 executes the signer's intent and authenticates the signer as the authorizing party of the operation through privileged access to the key. At least one key required to sign the transaction is securely stored in the hardware security module 105 and never leaves. In some embodiments, the hardware security module 105 reinforces these policies through a secure execution environment (SEE) that runs code that cannot be modified except through physical access to the hardware security module 105 and requires a set of smart cards securely held by multiple employees of the crypto asset custodian.

[0047] In some embodiments, to facilitate the above functionality, the hardware security module 105 stores multiple instances of a data structure referred to as an "organization" in its internal storage 107, with one instance stored for each client of the crypto asset custodian. In one implementation, the organization data structure may include the following fields: an identifier (ID) of the organization, the name of the organization, the organization's public key, a list of users belonging to the organization, a policy graph, a list of vaults belonging to the organization and their respective policy graphs, and a generation number that increments with each update to the organization structure. A "policy graph" is a set of policies that includes a policy for each possible action that can be performed (e.g., adding a user or changing a vault policy). The organization data structure is signed by the hardware security module 105 using the organization's private key (which cannot be read by any external entity) to indicate that the organization data structure was generated through a valid set of changes authorized by users and risk assessors. In some embodiments, the hardware security module 105 keeps track of the latest version to prevent rollback attacks. In other embodiments, the code of the hardware security module 105 is versioned, and checks are performed during upgrades to prevent rollback attacks.

[0048] To add new customers, the hardware security module 105 creates a new organization instance. To help ensure adequate security, the hardware security module 105 can create the organization for the requested set of users. In some embodiments, the hardware security module 105 generates a new, unique key for each new organization created. Thus, because each organization has a unique organization key, attackers are prevented from attempting to spoof or copy the identity (ID) of an existing organization.

[0049] Figure 4 Examples of processing that can be performed by hardware security module 105 in response to a request to perform an operation are shown in at least some embodiments. This request may be received by hardware security module 105 from relay server 103. Initially, hardware security module 105 receives (step 401) an operation description specifying the organization from relay server 103. This operation description is a set of data and metadata describing the requested operation (such as the requested deposit, withdrawal, or transfer of cryptocurrency). Hardware security module 105 verifies (step 402) the integrity of the specified organization.

[0050] Hardware security module 105 searches for policies in the organization's or vault's policy graph (step 403). Hardware security module 105 examines the policies of internal risk reviewers to determine which internal risk endorsements must be made and how many (i.e., endorsements from personnel at the crypto asset custodian) (step 404). Hardware security module 105 can determine (step 405) whether any of the crypto endorsements received (from the user) indicate a "REJECT" for the requested operation. If "yes," hardware security module 105 can reject the requested operation by returning a "REJECT" message to the relay server (step 411), which returns a corresponding "REJECT" message to the server computer to notify the requester. Hardware security module 105 does not bother to check any further signatures and simply rejects the operation.

[0051] Hardware security module 105 determines (step 406) whether all received cryptographic endorsements for the transaction are valid. This determination includes verifying the validity of the provided cryptographic endorsements by checking the following: i) the user is in the organization; ii) the signature is correct for the specified operation; and iii) each signature has an "approval" decision. If not all received cryptographic endorsements for the transaction are valid, the process proceeds to step 411 as described above.

[0052] If all received cryptographic endorsements for the transaction are valid, the hardware security module 105 determines (step 407) whether the cryptographic endorsements satisfy the relevant policy of the target cryptographic asset (i.e., satisfy the specified number). If a valid cryptographic endorsement does not satisfy the policy, the process proceeds to step 411 as described above. If the cryptographic endorsement satisfies the policy, the hardware security module 105 determines (step 408) whether the requested operation passes the risk analysis module 104. If it is "no", the process proceeds to step 411 as described above. If the requested operation passes the risk analysis module 104, the hardware security module 105 determines (step 409) whether the requested operation is valid. This determination step may include verifying that the operation is internally consistent and can be applied to the organization, vault, or cryptographic asset to which the operation is targeted. If the requested operation is invalid, the process proceeds to step 411 as described above. Otherwise, the hardware security module 105 executes (step 410) the requested operation (or triggers an action that causes the operation to be executed). Operations that alter an organization, vault, or strategy result in a new, signed organizational data structure with a higher generated value and applied changes. Operations that retrieve crypto assets cause the hardware security module 105 to sign the blockchain transaction using the private key corresponding to the object crypto asset. Operations that deposit crypto assets cause the hardware security module 105 to generate a deposit address.

[0053] Figure 5 This is a flowchart illustrating an example of processing for endorsing a requested transaction using an offline user device. As a method to reduce the risk of users interacting with crypto asset custody system applications on their personal devices, the crypto asset custody system 100 may require authorization from an offline device. This offline device (such as a consumer phone with a securely designated address space, or a computing device with similar functionality like an iPod Touch or personal digital assistant) is completely disconnected from the internet under normal conditions and is used offline to sign the transaction required for authorization.

[0054] The process can be performed as follows: The user's phone or similar device is a designated number of members of his or her vault policy and is not connected to any wireless or cellular network. The device runs software similar to, or the same software operating in a different mode, the application software used to enable the user to endorse the requested transaction. The user initiates a transaction for his or her vault through one of the designated number of devices. Online devices, such as other phones or web browsers, have access to the transaction. The online devices can be other phones / security devices within the designated number, or the online devices may exist solely to display the transaction. The device is able to transmit data that requires signature by the offline device to the offline device. This transmission can be achieved through channels not accessible via the Internet (such as displaying a QR code, playing an encoded sound or sound sequence, or transmitting via Bluetooth). The offline device displays the transmitted data for the offline device's signature, allowing the user to approve or reject it. The offline device signs the endorsement of the operation based on the user's desired action. The offline device sends its signed payload communication back to the online device in a manner similar to that used for receiving (e.g., displaying a QR code, playing an encoded sound or sound sequence, or transmitting via Bluetooth). The online device then sends the signed decision payload communication back to the server computer of the crypto-asset custody system 100.

[0055] exist Figure 5In this process, the online user device receives an operation description from the encrypted asset custody system 100 via the Internet (step 501). The online user device (e.g., user device 108) transmits the operation description (or a portion thereof) to an offline user device using an offline channel (step 502). As described above, an offline channel is a channel that cannot be accessed via the Internet, such as using the online user device's local visual display, sound or sound sequences generated by the online user device, or (e.g., via Bluetooth) short-range wireless transmission from the online user device. The offline user device receives the operation description from the online user device via the offline channel (step 503), and based on the information received therefrom, displays the operation description (or a portion thereof) and prompts the user for endorsement of the operation (step 504). If the offline device receives a valid endorsement as user input within the timeout period (step 505), the offline device sends an "Accept (ACCEPT)" message to the online user device via the same offline channel through which the offline device received the operation description or via a different offline channel (step 506). The online user device receives the result of the encrypted endorsement from the offline device (step 507) and transmits the result payload to the encrypted asset custody system via the Internet (step 508). If the offline user device does not receive a valid encrypted endorsement from the user within the timeout period (step 505), the offline user device transmits a "REJECT" message to the online user device via the offline channel, whereby the online user device then transmits the "REJECT" payload to the encrypted asset custody system via the Internet (step 508).

[0056] Offline devices can be delivered to users in a state that is pre-registered in the organization with their security keys, or offline devices can be allowed to go online for initial registration processing, or offline devices can send their registration through the same process as authorization processing.

[0057] Periodic updates to the crypto asset custody system software on offline devices may be required. In some embodiments, to allow such updates, the offline device is scheduled to connect to the Internet via Wi-Fi and update its software at a predefined pace. In other embodiments, the offline device detects that it needs to update its software as a result of receiving a transaction to be signed from an online user device (indicating that the software version on the offline device is no longer compatible). Whenever the device is online, it may record the fact that it has Internet access and attempt to transmit this fact to the crypto asset custody system 100 so that this information can be used by the platform to assess risk at a later time. In other embodiments, the offline device does not require Wi-Fi. For example, the offline device is connected to a laptop computer capable of updating its software.

[0058] In addition to remaining offline, offline user devices, as well as one or more online devices, can be restricted to taking action on transactions only within the range of a predefined beacon. Wireless (e.g., Bluetooth) beacon devices can be made available to the user, and the crypto asset custody system 100 application can refuse to authorize transactions unless a beacon is detected as available.

[0059] Each transaction submitted to the crypto asset custody system 100 is recorded in an internal ledger that is tamper-proof and allows auditors to have cryptographic evidence of every historical event in each user's account. Ownership of blockchain crypto assets is controlled by possessing a private key corresponding to a public wallet address. The crypto asset custody system 100 can prove ownership of these crypto assets to the auditor by signing a randomly selected string of text chosen by the auditor using the private key corresponding to the user's vault. Consider the following example:

[0060] The auditor wanted to see evidence that the crypto asset custody system 100 had access to funds in a wallet identified by the address “1BvBMSEYstn5Au4m4GFg7yJaNVN2”. Therefore, the auditor randomly generated a long string (e.g., “xGG8vQFnd8QDwHz6Uj1GX”) and submitted the following challenge:

[0061] {

[0062] Address: 1BvBMSEYstn5Au4m4GFg7yJaNVN2

[0063] Token: "AUDIT-CHALLENGE-xGG8vQFnd8QDwHz6Uj1GX",

[0064] }

[0065] The crypto asset custody system 100 receives a challenge and forwards it as a predefined, templated serialized packet to the hardware security module 105. The hardware security module 105 is programmed to accept such audit requests (which are not arbitrary payloads, thus eliminating the risk of them being subsequently interpreted as signed blockchain transactions) and sign these audit requests with the private key associated with the specified address. The crypto asset custody system 100 returns a valid signature for queries that can be independently verified by an auditor. This verification proves that the crypto asset custody system 100 controls the private key corresponding to the entry on the blockchain, thereby providing proof of control over the crypto assets.

[0066] In some embodiments, the crypto asset custody system 100 includes a thresholding service that enables other parts of the system (risk analysis module 104 and hardware security module 105) to securely determine that user operations and transactions follow client-specific business logic and have been approved by an automated risk assessment system. The thresholding service can verify a specified number of multi-signature (multi-user) transactions.

[0067] Thresholding services validate user-initiated and approved operations to ensure they meet a threshold threshold before execution. Such operations can include transactions or adding or removing other users. Different users can have different access control roles (e.g., view-only, transaction-only, authorized, required). The crypto asset custody system 100 can notify each reportable condition of a specified number of accepted lifetimes, but cannot sign off on operations not authorized by the client. All actions are logged to an append-only ledger for auditability of all account interactions.

[0068] One function of the thresholding service is to verify that a specified number of authorized users have signed their consent to the requested action. Qualified actions that may require a specified number could include, for example, submitting a transaction, adding a user to an account, changing a user's permissions, removing a user from an account, and modifying the thresholding logic. The specified number can be defined by default as an absolute majority of users (e.g., 3 out of 5), or it can be set to a custom specified number when a customer joins. Furthermore, authorized users can configure the specified number to require certain specific users to endorse a transaction to constitute the specified number. The crypto asset custody system 100 can also allow thresholding across multiple desired groups. For example, in a company, it might require the consent of a majority of the finance team and management.

[0069] In some embodiments, the thresholding service implements a fine-grained access control model in its specified number of verifications, where different users can have different access levels, which may include, for example:

[0070] -View only

[0071] This is the default access level.

[0072] Users at this level can view the location of all crypto assets.

[0073] - Users at this level can tag any transaction.

[0074] Users at this level can freeze all their crypto assets.

[0075] -View-Authorization

[0076] Users at this level can act as authorized voters to push for a specified number of actions.

[0077] Users at this level can view the location of all crypto assets.

[0078] - Users at this level can tag any transaction.

[0079] Users at this level can freeze all their crypto assets.

[0080] -View-Authorize-Required

[0081] - Users at this level are the required voters for the action.

[0082] Users at this level can view the location of all crypto assets.

[0083] - Users at this level can tag any transaction.

[0084] Users at this level can freeze all their crypto assets.

[0085] In some embodiments, a user's access level may change only with the appropriate number of verification requirements verified through the thresholding service.

[0086] As described above, user approval of an action can be represented by a cryptographic digital signature to benefit from non-repudiation guarantees. The crypto asset custodian can determine that the associated user holding the private key is indeed the user who approved the action because the digital signature is unforgeable. In some embodiments, the user's signature is generated from the iOS secure designated address space in the user's mobile device and forwarded to the crypto asset custodian system 100 by the iOS application programming interface (API) component in user device 108. The cryptographic hash of the transaction content can be signed to ensure the transaction cannot be tampered with. It may be necessary for all users to sign the same hash with the same transaction identifier (ID) to ensure that signatures are counted in a predetermined number. A thresholding service can provide templates for client signing and can verify all completed signatures made by the iOS client. In at least some embodiments, the thresholding service verifies signatures using a public component of the user signing keys but does not hold the private component of these user signing keys.

[0087] Once the threshold is met, the thresholding service publishes the corresponding signature data to the risk analysis module 104 for further analysis before signing consent. The risk analysis module 104 also serializes the signature data into a payload to be consumed by the hardware security module 105's signature service. Each additional signature provided to the thresholding service and for verification can be recorded in an append-only log service. This log, in addition to providing metadata captured in the thresholding service's storage, will also provide additional auditing and status updates, which is crucial for providing consumable updates to user clients.

[0088] Assume a predetermined number of authorized members are available for cryptographic signing of transactions. Therefore, this predetermined number should remain "active," meaning that at any given time, the crypto asset custody system 100 has a reasonable level of confidence that all potential members maintain possession of their security device keys and can actively participate in transactions. In some embodiments, the crypto asset custody system 100 may achieve this level of confidence by:

[0089] 1. Has the right to access the set of user public keys required to implement the policy.

[0090] 2. Set an activity threshold for the strategy, i.e., a time period after which the key is considered at risk of becoming unusable. This threshold can be fixed or related to the normal transaction rhythm.

[0091] 3. Require users to periodically sign proof transactions using their private keys. This can be done explicitly as an activity check, or implicitly through regular operations such as login that require their keys.

[0092] 4. Record the latest active time of the key of any one or more users.

[0093] 5. Continuously monitor whether any user's active time exceeds the activity threshold.

[0094] 6. Use the above information to prompt users to prove that these users still have the right to access their signing keys and / or to notify other users of the specified amount of potential risks.

[0095] The risk analysis module 104 can implement an API known as the Risk API, and may also include review and management of user actions for all transactions. In some embodiments, the Risk API drives the review system. The Risk API can provide integration with an internal risk dashboard for reviewing individual transactions.

[0096] In some embodiments, all transactions are manually approved by (one or more) designated employees; all administrative user operations (addition, deletion, permission changes) are manually approved by (one or more) designated crypto asset custodian employees; the auditable entity must pass an automated verification process before risk analysis is required; the auditable entity must provide robust context related to user approval for automated checking; and risk approvals and rejections are logged in an append-only ledger for auditing purposes.

[0097] The Risk API re-verifies the appropriate threshold determined by the thresholding service. The Risk API can also handle additional business logic, such as in a simplified embodiment where the thresholding service is used: for example, if the thresholding service only checks a specified number, the Risk API can check the required signers. Other functionalities described herein can also be moved between modules.

[0098] The risk API can receive contextual data related to the various users involved in a transaction, which can then be presented to a classification system. This data may include, for example, the user (one or more) who approved the transaction, the time of approval, the location of approval, and the device / key ID that approved the transaction. This data can be fed into an internal risk analysis dashboard and, possibly, into other automated review systems.

[0099] In some embodiments, if a transaction passes an automated risk review, the risk API requires approval. For approval, an employee may need to sign the transaction / operation with an encryption key and present that signature to the risk API for verification. Furthermore, it is preferable to have multiple keys (one for each risk reviewer) so that the individuals who have reviewed the transaction are logged. Preferably, the risk approval key is easily rotated even in the event of a breach.

[0100] Figure 6 An example block diagram of a crypto asset custody system 100 that uses data points from mobile devices 604 and 608 for risk mitigation is shown. (See reference...) Figure 1 In more detail, the encrypted asset custody system 100 includes a server computer 102, a relay server 103, a hardware security module 105, a risk analysis module 104, and a data storage facility 106.

[0101] Server computer 102 is a computer device that includes software that provides functionality for client programs and devices (e.g., user device 108). Server computer 102 provides various functions, such as requesting user device 108 to endorse crypto-asset transactions, communicating with hardware security module 105, and performing crypto-asset transactions on blockchain 111 in response to client requests. For example, server computer 102 transmits endorsement requests for crypto-asset transactions to be performed by server computer 102 on blockchain 111 to multiple user devices 108. User devices 108 may be smartphones, tablets, laptops, or desktop computers. Each user device 108 is communicatively coupled to server computer 102, for example, using network 109. Network 109 is a public computer network, such as a reference network. Figure 1 The Internet, etc., are shown and described in more detail. Each user device 108 is associated with a user of the encrypted asset custody system 100.

[0102] The endorsement request is configured to prompt each user device 108 to endorse a crypto-asset transaction. Each user is defined as a predetermined number of potential members involved in crypto-asset transactions. In this context, an endorsement is a user's approval or rejection of an operation. When a user who receives such a prompt endorses a transaction on his or her user device 108, the user device 108 signs the crypto-endorsement with the user's private key and transmits the signed crypto-endorsement to the server computer 102. This private key is stored in a secure designated address space 114 within the user device 108. The secure designated address space 114 in each user device 108 is used to store the corresponding user's private key and generate the user's digital signature.

[0103] Mobile devices 604 and 608 are smartphones, wearable technology devices, or smart electronic devices that can be incorporated into clothing or worn on the body as implants or accessories. Mobile devices 604 and 608 include a microprocessor, application-specific integrated circuit (ASIC), touchscreen, or GPS receiver to provide various functionalities. Mobile devices 604 and 608 can be implementations of the Internet of Things (IoT), which enables objects to exchange data with connected devices (e.g., user device 108) via the Internet without human intervention. Each mobile device 604 and 608 is communicatively coupled to user device 108, for example, using Bluetooth, Wi-Fi, radio frequency communication, network 109, or a combination thereof. Each mobile device 604 and 608 is associated with a user associated with user device 108.

[0104] Mobile device 604 may be an activity tracker or fitness tracker that monitors and tracks a user's fitness-related metrics, such as walking or running distance, calorie consumption, and, in some cases, heart rate. Smartwatch 608 is a wearable computer in the form of a wristwatch, providing a native touchscreen interface and including an associated smartphone application (app) for management and telemetry (such as long-term biometric monitoring). Other examples of mobile devices that may be part of some or all of the embodiments disclosed herein are devices for performing tasks such as calculations, digital time notification, translation, playing games, etc., and may include mobile applications, a mobile operating system, and WiFi / Bluetooth connectivity. Other examples of mobile devices include portable media players with an FM radio and playback of digital audio and video files via Bluetooth headphones.

[0105] In some embodiments, user device 108 prompts the user to capture one or more data points when endorsing a crypto asset transaction. For example, the user may be prompted to use user device 108 or a mobile device (e.g., such as 604, 608, etc.) to take a photograph of her face. The photograph is thus a data point. In other embodiments, mobile devices 604, 608 may collect multiple data points associated with the user once the user has consented. Data points represent the user's identity. For example, smartwatch 608 or fitness tracker 604 may include a Global Positioning System (GPS) receiver. The GPS receiver measures the geographic location (coordinates) of smartwatch 608 or fitness tracker 604. Therefore, data points may include geolocation and time information. Data points may include an identification number of one of mobile devices 604, 608. For example, the identification number may be a Mobile Identifier (MIN) or Mobile Subscriber Identifier (MSIN), a 10-digit unique number used by wireless operators to identify smartphones.

[0106] The data point may include the altitude of mobile devices 604 and 608 relative to sea level, measured by their GPS receivers or barometer sensors. For example, mobile devices 604 and 608 can determine their altitude by measuring their distance from the orbital centers of GPS satellites. The data point may include the Service Set Identifier (SSID) of the wireless network to which mobile devices 604 and 608 are connected. SSID refers to the identifier of a Wi-Fi network. Mobile device 604 or user device 108 may also connect to a printer via the SSID. Therefore, the data point may also include the identifier or IP address of the connected printer. The data point may include the Bluetooth device address of mobile devices 604 and 608. The Bluetooth device address (or BD_ADDR) is a unique 48-bit identifier assigned to each Bluetooth device by the manufacturer.

[0107] Data points may include biometric data of the user captured by user device 108 or mobile devices 604, 608. Biometric data may include the user's heart rate, temperature, voice samples, photographs, or video recordings. (Reference) Figure 3B Additional examples of data points are described in more detail. In some embodiments, data points captured by mobile devices 604, 608 are transmitted to user device 108, which then transmits these data points to server computer 102. In other embodiments, once user device 108 notifies mobile devices 604, 608 of an endorsement request, mobile devices 604, 608 can transmit data points directly to server computer 102.

[0108] Data points can include transaction amounts denominated in US dollars, other currencies, or cryptocurrencies. For example, once a withdrawal request is received, the risk analysis module 104 can plot the requested withdrawal amount and previous withdrawal amounts on a scatter plot. The scatter plot can include, for example, USD valuation on the Y-axis and time on the X-axis. Highlighting current and future withdrawals allows the risk analysis module 104 to determine whether the current withdrawal request amount is an outlier or suspiciously high. In some embodiments, data points and their trends are displayed on a risk assessment dashboard in the form of a graphical user interface. Trends can be displayed graphically as scatter plots, histograms, bar charts, line charts, or pie charts. The graphical user interface enables interaction with the risk assessment dashboard through graphical icons and visual indicators such as auxiliary symbols, text-based user interfaces, typed command labels, or text navigation. Approver can check whether data points match expected values ​​before signaling their approval of crypto-asset transactions.

[0109] Risk analysis module 104 conducts a risk-based review of communications (endorsement, approval) for crypto asset transactions before they can proceed. (Reference) Figure 1 The risk analysis module 104 is shown and described in more detail, and it can be implemented in hardware or software. The risk analysis module 104 is communicatively coupled to the server computer 102. The risk analysis module 104 generates a graphical visualization of data points on a risk assessment dashboard. An automated risk analysis agent can evaluate the risk assessment dashboard to determine whether a crypto asset transaction has been adequately authorized and accepted.

[0110] The graphical visualization may include a risk metric based on multiple data points. The risk metric represents the risk of accepting crypto-endorsement for crypto-asset transactions from user device 108. The risk metric can be a number between 0 and 100 (0 representing minimum risk and 100 representing maximum risk), or a number between 0.00 and 1.00. In some embodiments, the risk metric is a vector of risk scores that include different categories (e.g., the risk of a malicious actor possessing the user's mobile device 604, the risk of crypto-endorsement being fraudulent, the risk of the mobile device malfunctioning).

[0111] Generating graphical visualizations includes determining whether certain data points match the expected values ​​of multiple data points. For example, if a user carries user device 108 and wears smartwatch 604, the GPS locations reported by both devices are expected to be the same. If the locations do not match, the risk metric increases. Graphical visualizations can include trends in how data points change over time. If there is a significant change in the biometrics measured by mobile devices 604 and 608 compared to values ​​measured over time, the risk metric increases. For example, if a user's heart rate was previously 80 and the smartwatch measures a heart rate of 95, a mismatch is detected. Therefore, the risk analysis module 104 can predict the expected value of each data point based on trends.

[0112] In some embodiments, server computer 102 transmits an endorsement request for a crypto asset transaction to user device 108. This endorsement request is configured to prompt user device 108 to endorse the crypto asset transaction. Server computer 102 receives multiple data points collected from one or more mobile devices (e.g., 604, 608). These data points represent the user's identity. Risk analysis module 104 generates a graphical visualization of the multiple data points on a risk assessment dashboard. The graphical visualization may include scatter plots, histograms, bar charts, line charts, pie charts, or other forms of graphical visualization. The graphical visualization may be reviewed by risk experts or transmitted to other entities for review.

[0113] In some embodiments, as described above, server computer 102 receives multiple data points collected from one or more mobile devices. Risk analysis module 104 generates a risk metric based on the multiple data points. The risk metric represents the risk of receiving cryptographic endorsement for a crypto asset transaction from user device 108. To generate the risk metric, risk analysis module 104 can determine whether a data point matches an expected value. For example, the risk metric can be a function of the difference between the measured value of a data point and the expected value. Risk analysis module 104 can also calculate a trend for the multiple data points and determine the expected value of the data points based on the trend. Each mobile device (e.g., 604, 608) may have required or unnecessary conditions. Therefore, risk analysis module 104 can detect the absence of data points from a particular mobile device, where that particular mobile device is assigned a required condition. In this case, risk analysis module 104 can increase the risk metric in response to the detection of absence. Hardware security module 105 can be configured to receive cryptographic endorsement for a crypto asset transaction from server computer 102 via relay server 103 in response to a risk metric falling below a threshold.

[0114] In some embodiments, the risk analysis module 104 registers each mobile device (e.g., 604, 608) associated with a user on the crypto asset custody system 100 before receiving data points. Registration of mobile devices (e.g., 604, 608) is performed in response to a registration request received from user device 108. The registration request associates the user of the crypto asset custody system 100 with each mobile device 108. For example, data associating the identifier of user device 108 with the identifiers of mobile devices 604, 608 can be stored in data storage facility 106. If the server computer 102 receives data points from an unregistered mobile device, the risk metric increases, reflecting that a hacker may be tampering with the crypto asset custody system 100.

[0115] In some embodiments, registering mobile devices 604, 608 includes assigning necessary or unnecessary conditions to the mobile devices 604, 608. Necessary conditions may be represented by a binary "1" value encoded into the registration process. Unnecessary conditions may be represented by a binary "0" value encoded into the registration process. For example, a user may be required to always carry his or her smartwatch 608, but may not be required to always wear his or her fitness tracker 604. Risk analysis module 104 detects the absence of data points collected from mobile device 608, where mobile device 608 has been assigned a necessary condition (binary "1"). For example, risk analysis module 104 detects that no data is received from smartwatch 608. Risk analysis module 104 increases a risk metric in response to detecting the absence of a signal from such a device.

[0116] In some embodiments, the risk analysis module 104 detects a mismatch between a first data point and a second data point among a plurality of data points, the first data point being collected from a first mobile device among one or more mobile devices, and the second data point being collected from a second mobile device among one or more mobile devices. For example, a smartwatch 608 may measure a user's heart rate as a value R1. A fitness tracker 604 may measure a user's heart rate as another value R2. If a significant difference exists between R1 and R2 (e.g., a difference of 50), the risk analysis module 104 increases the risk metric.

[0117] In some embodiments, the risk analysis module 104 includes a feature extraction module and a machine learning module communicatively coupled to the feature extraction module. The feature extraction module extracts or determines one or more feature vectors from data points. See the following reference... Figure 8The feature extraction can be implemented in software or using dedicated hardware. The feature extraction module reduces redundancy in the data points by transforming them into simplified feature sets (feature vectors). In some embodiments, the feature extraction module can use dimensionality reduction techniques such as Independent Component Analysis, Isomap, kernel PCA, Latent Semantic Analysis, Partial Least Squares, or multi-factor dimensionality reduction to reduce the dimensionality of the feature vectors. The feature vectors contain relevant information from the data points, allowing the machine learning module to use simplified representations instead of data points to identify features of interest.

[0118] The machine learning module generates a risk metric based on feature vectors. The machine learning module is trained to represent the risk of accepting cryptographic endorsement based on whether multiple data points match the expected values ​​of those data points. The machine learning module includes mathematical and connectivity models trained to make predictions or decisions without explicit programming. The crypto asset custody system 100 can use one or more machine learning methods to train the machine learning module. In one embodiment, the k-nearest neighbor method is used. The k-nearest neighbor method can be used for both classification and regression. For both classification and regression, the training dataset consists of the k closest training examples in the feature vector space. In some embodiments, the support vector machine method is used. The support vector machine uses supervised learning to train the machine learning module with associative learning algorithms, where these associative learning algorithms analyze feature vectors used for classification and regression analysis. A set of training examples is presented to the machine learning module, each labeled as belonging to one of two categories or the other. The support vector machine method trains the machine learning module to assign new examples to one category or the other, thus making the machine learning module a non-probabilistic binary linear classifier.

[0119] If the risk analysis module 104 determines that the risk metric is below the threshold risk metric, then the server computer 102 transmits the cryptographic endorsement of the crypto asset transaction to the hardware security module 105 via a relay server 103 communicatively coupled to the server computer 102. (Reference) Figure 1 The relay server 103 is shown and described in more detail. For example, for a risk metric range of 0 to 100 (where 0 represents lower risk), a threshold risk metric can be selected as 10 for more secure operations. The server computer 102 only transmits the cryptographic endorsement of the crypto asset transaction to the hardware security module 105 when the risk metric is determined to be less than 10. For less secure operations, the threshold risk metric can be set higher. The threshold risk metric can be determined based on historical data and trends in data point values.

[0120] The hardware security module 105 is a dedicated physical computing device that protects and manages the digital keys used for authentication and provides a secure execution environment. (Reference) Figure 1Hardware security module 105 is shown and described in more detail. Hardware security module 105 is communicatively coupled to relay server 103. Hardware security module 105 receives cryptographic endorsements for cryptographic asset transactions from relay server 103. Hardware security module 105 generates cryptographic keys associated with cryptographic asset transactions. (Reference) Figure 1 , Figure 2B and Figure 3B The generation of the encryption key is described in more detail. The encryption key can be used to control access to blockchain 111. (Reference) Figure 1 Blockchain 111 is described in more detail.

[0121] Data storage facility 106 may include one or more databases, which may be or include relational databases or any other type of institution for organizing and storing data of the crypto asset custody system 100, wherein the data may be structured and / or unstructured. (See reference) Figure 1 The data storage facility 106 is shown and described in more detail.

[0122] Figure 7 The trend 700 of the data points collected from mobile devices 604 and 608 is shown. (Reference) Figure 6 Mobile devices 604 and 608 are shown and described in more detail. Trend 700 shows different data points captured at four different time points. Data point 704 is a user image captured at 9:43 AM on March 10th when the user endorsed the first crypto asset transaction. Data point 704 appears to be an image of a woman. Therefore, when data point 716 is captured at the second time point, image 704 will be the expected value of the user's image. Data point 708 is the location of the user (or at least the capturing device) detected at 9:43 AM on March 10th when the user was endorsing the first crypto asset transaction. Data point 708 shows the user's location as San Francisco. Therefore, San Francisco will be the expected value of the location at the next detection (e.g., data point 720). Data point 712 captures the number of steps the user took up to 9:43 AM on March 10th when the user was endorsing the first crypto asset transaction. The number of steps can be determined by... Figure 6 The fitness tracker 604 captured the data. Data point 712 shows the steps as 4062. Data can be captured or collected as per reference. Figure 6 Other data points mentioned above. User device 108 or server computer 102 can also derive metrics from the collected data points. For example, the number of steps taken can be converted into a step-per-hour metric or a step-per-minute metric, allowing the metric to be normalized over the capture time. Thus, the step count of 4062 can be divided by 9 hours and 43 minutes to derive a step-per-minute metric of 4062 / 583 or 6.97 steps / minute, where 9 hours and 43 minutes equals 583 minutes.

[0123] Data point 716 is an image of the user captured at 3:19 PM on June 7th, when the user was endorsing the second cryptocurrency transaction. In image 716, the user is wearing glasses. Risk analysis module 104 determines whether image 716 matches the expected value (the face in image 704) through, for example, image processing and facial recognition. Data point 720 is the user's location detected while the user was endorsing the second cryptocurrency transaction. Data point 720 shows the user's location as San Francisco. Location 720 matches the expected value (San Francisco). Data point 724 captures the number of steps the user took up until the user endorsed the second cryptocurrency transaction. Data point 724 shows the number of steps as 7217. Although the number of steps 7217 is not equal to 4062, risk analysis module 104 can determine a match based on the capture time. For example, the step count 7217 can be divided by 15 hours and 19 minutes (3:19 PM) to derive a step-per-minute metric of 7217 / 919 or 7.85 steps / minute, where 15 hours and 19 minutes equals 919 minutes after midnight the previous day. In some embodiments, the risk analysis module 104 can set a threshold for the difference from the expected value, where endorsement can be rejected if the difference is higher than the threshold. For example, a threshold of 100 steps / minute can be set. Here, the difference 7.85 - 6.97 is less than 100. Therefore, data point 724 is determined to match data point 712. This threshold can be set lower for a more stringent match or higher for a more lenient match. Since data points 716, 720, and 724 match the expected values ​​based on data points 704, 708, and 712, they are accepted for cryptographic endorsement.

[0124] Data point 728 is a user image captured at 3:55 PM on August 17th when the user endorsed a third-party cryptocurrency transaction. In image 728, the user is not wearing glasses, but image 728 appears to be the same woman. Risk analysis module 104 determines a match based on data points 704 and 716 (expected values) using, for example, image processing and facial recognition. Data point 732 is the user's location detected at 3:55 PM on August 17th. Data point 732 shows the user's location as New York. Therefore, location 732 is not equal to the expected values ​​(locations 708 and 720). However, if enough other data points match, risk analysis module 104 determines that the user has previously logged in from New York, or if other identifiers of the user (e.g., residential or office address) are in New York, the location mismatch can be ignored. Data point 736 captures the number of steps the user took up to 3:55 PM on August 17th. Data point 736 shows the number of steps as 7673. If the difference is less than the threshold difference from the expected value (e.g., the average of 7.85 and 6.97 steps / minute), the risk analysis module 104 can determine that it is a match.

[0125] Data point 740 is an image of the alleged user captured at 6:12 PM on August 19th while the user was endorsing the fourth crypto asset transaction. Image 740 is an image of a person with a beard and appears to be male. Risk analysis module 104 determines that data point 740 does not match the expected value. Data point 744 is the user's location detected at 6:12 PM on August 19th while the user was endorsing the fourth crypto asset transaction. Data point 744 shows the user's location as San Francisco. Therefore, location 744 matches the expected value (locations 708, 720). However, other data points with significant mismatches can negate the location match. For example, data point 748 captures the number of steps the user had taken up to 6:12 PM. Data point 748 shows the number of steps as 11. Since the derived steps / minute metric is 11 / 1092 or 0.01 steps / minute (where 1092 minutes equals 18 hours and 12 minutes after midnight (6:12 PM)), the risk analysis module 104 can determine a mismatch. The metric of 0.01 steps / minute differs significantly from the expected value of approximately 7 steps / minute. Because data points 740 and 748 do not match the expected value based on previously collected data points, the cryptographic endorsement is rejected. The cryptographic asset custody system 100 can further investigate, contact the user to gather more information, or rely on other data points such as the SSID of the Wi-Fi network to which the mobile device 604 is connected, other biometric data, the brand and model of the smartphone, the mobile device's identifier, or the user's mobile device's Bluetooth address.

[0126] Figure 8 This illustrates risk mitigation procedures 800 for a crypto asset custody system 100. (Reference) Figure 1 and Figure 6 The crypto asset custody system 100 is shown and described in more detail. In some embodiments, Figure 8 The processing 800 is performed by the crypto asset custody system 100. In other embodiments, other entities (e.g., user device 108 or mobile device 604) perform some or all of the steps of processing 800. See reference. Figure 1 User device 108 is shown and described in more detail. References Figure 6 The mobile device 604 is illustrated and described in more detail. Similarly, embodiments may include different and / or additional steps, or these steps may be performed in a different order.

[0127] The crypto asset custody system 100 transmits (804) an endorsement request for a crypto asset transaction to a user device 108 associated with a user of the crypto asset custody system 100. This endorsement request is transmitted by a server computer 102 of the crypto asset custody system 100 (e.g., server computer 102). [Reference] Figure 1 and Figure 6Server computer 102 is shown and described in more detail. User device 108 is communicatively coupled to server computer 102. Cryptographic asset transactions will be conducted by server computer 102 on blockchain 111. (Reference) Figure 1 Blockchain 111 is shown and described in more detail. The endorsement request is configured to prompt the user device 108 to endorse a cryptocurrency transaction.

[0128] The encrypted asset custody system 100 uses a server computer 102 to receive (808) multiple data points. These data points are collected from one or more mobile devices (e.g., 604, 608) communicatively coupled to a user device 108. These mobile devices (e.g., 604, 608) are associated with a user. The multiple data points can represent the user's identity. For example, mobile device 608 could be the user's smartwatch. The data points could include the geographic location of smartwatch 608 as measured by a GPS receiver on smartwatch 608.

[0129] The crypto asset custody system 100 uses a server computer 102 to receive (812) cryptographic endorsements of crypto asset transactions from user devices 108. For example, when a user receiving an endorsement request endorses a crypto asset transaction on his or her user device 108 (e.g., a smartphone, tablet, or laptop), the user device 108 signs the cryptographic endorsement with the user's private key and transmits the signed cryptographic endorsement to the server computer 102. This private key may be stored in a secure designated address space 114 within the user device 108. The secure designated address space 114 in each user device 108 is used to store the private key of the corresponding user and generate the user's digital signature. (See reference...) Figure 1 The secure designated address space 114 is shown and described in more detail.

[0130] The crypto asset custody system 100 can use the risk analysis module 104 to generate (816) graphical visualizations including risk measures based on multiple data points. (See reference) Figure 1 and Figure 6 The risk analysis module 104 is shown and described in more detail. The risk analysis module 104 is communicatively coupled to the server computer 102. The risk metric represents the risk of endorsing a cryptocurrency transaction from the user device 108. To generate a graphical visualization, the risk analysis module 104 determines whether multiple data points match expected values. The graphical visualization may include trends in how the data points change over time. The risk analysis module 104 may determine the expected value for each data point based on this trend.

[0131] In response to a risk metric falling below a threshold risk metric, the crypto asset custody system 100 transmits the crypto endorsement of the crypto asset transaction from the server computer 102 (820) to the hardware security module 105 of the crypto asset custody system 100. Reference Figure 1 and Figure 6 The hardware security module 105 is shown and described in more detail. This transmission is performed via a half-duplex relay server 103 of the encrypted asset custody system 100. The hardware security module 105 is communicatively coupled to the server computer 102 via the half-duplex relay server 103. (Reference) Figure 1 The half-duplex relay server 103 is shown and described in more detail.

[0132] The crypto asset custody system 100 utilizes hardware security module 105 to generate (824) cryptographic keys. These cryptographic keys are associated with crypto asset transactions and can be used to control access to blockchain 111. For example, addresses where cryptocurrency is deposited on blockchain 111 can be stored in a collection (referred to as the customer's "vault") along with other addresses belonging to the user within the crypto asset custody system 100. In this context, a vault is a data entity containing crypto assets and a strategy graph containing one or more strategies for managing the deposits and withdrawals of these crypto assets. Crypto assets are represented as slots within the vault that can hold a certain amount of a crypto asset type (e.g., Ethereum). Once custodied and stored using the crypto asset custody system 100, the crypto assets are available for trading.

[0133] Figure 9 This is a high-level block diagram illustrating an example of a hardware architecture that can be used to implement part or all of the processing system 900 in the crypto asset custody system 100 or user device 108. The crypto asset custody system 100 may include, for example... Figure 9 One or more instances of the architecture shown, wherein multiple such instances may be coupled to each other via one or more dedicated networks.

[0134] The illustrated processing system 900 includes one or more processors including a CPU 910, one or more memories 911 (at least a portion of which may be used as working memory, such as random access memory (RAM)), one or more data communication devices 912, one or more input / output (I / O) devices 913, and one or more mass storage devices 914, all of which are coupled to each other via interconnects 915. The interconnects 915 may be or include one or more conductive traces, buses, point-to-point connections, controllers, adapters, and / or other conventional connection devices. Each processor 910 controls part of the operation of the processing device 900 and may be or include, for example, one or more general-purpose programmable microprocessors, digital signal processors (DSPs), mobile application processors, microcontrollers, application-specific integrated circuits (ASICs), or programmable gate arrays (PGAs), or combinations of such devices.

[0135] Each memory 911 may be or include one or more physical storage devices, which may take the form of RAM, read-only memory (ROM) (which may be erasable and programmable), flash memory, small hard disk drive or other suitable types of storage devices, or combinations of such devices. Each large-capacity storage 914 may be or include one or more hard disk drives, digital versatile discs (DVDs), or flash memory, etc. Each memory 911 and / or large-capacity storage 914 may (individually or collectively) store data and instructions configured to (one or more) processors 910 to perform operations to implement the above-described technologies. Each communication device 912 may be or include, for example, an Ethernet adapter, a cable modem, a Wi-Fi adapter, a cellular transceiver, a baseband processor, or a Bluetooth or Bluetooth Low Energy (BLE) transceiver, etc., or combinations thereof. Depending on the specific nature and purpose of the processing system 900, each I / O device 913 may be or include devices such as a display (which may include a transparent AR display surface), audio speakers, a keyboard, a mouse or other pointing device, a microphone, or a camera, etc. However, note that if the processing device 900 is only embodied as a server computer, such an I / O device may be unnecessary.

[0136] In the case of a user device, the communication device 912 may be or include, for example, a cellular telecom transceiver (e.g., 3G, LTE / 4G, 5G), a Wi-Fi transceiver, a baseband processor, or a Bluetooth or BLE transceiver, or a combination thereof. In the case of a server, the communication device 912 may be or include, for example, any one of the communication devices of the types described above, a wired Ethernet adapter, a cable modem, or a DSL modem, or a combination of such devices.

[0137] Unless contrary to physical possibilities, it is contemplated that: (i) the methods / steps described herein can be performed in any order and / or in any combination; and (ii) the components of the various embodiments can be combined in any way.

[0138] The operations implemented by the aforementioned machine can be achieved through programmable circuitry programmed / configured by software and / or firmware, or entirely through dedicated (“hard-wired”) circuitry, or a combination of these forms. Such dedicated circuitry (if any) can take the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), or system-on-a-chip (SoCs).

[0139] The software or firmware used to implement the techniques described herein can be stored on a machine-readable storage medium and can be executed by one or more general-purpose or special-purpose programmable microprocessors. As used herein, the term "machine-readable medium" includes any means by which information can be stored in a machine-accessible form (a machine can be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, or any device having one or more processors). For example, machine-accessible media include recordable / non-recordable media (e.g., RAM or ROM; disk storage media; optical storage media; or flash memory devices), etc.

[0140] As used herein, the term "logic" means: i) dedicated hardwired circuitry, such as one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), or (one or more) other similar devices; ii) programmable circuitry programmed with software and / or firmware, such as one or more programmed general-purpose microprocessors, digital signal processors (DSPs) and / or microcontrollers, systems-on-a-chip (SoCs), or (one or more) other similar devices; or iii) a combination of the forms described in i) and ii).

[0141] As will be apparent to those skilled in the art, any or all of the features and functions described above can be combined with each other, except to the extent otherwise stated above, or to the extent that any such embodiments may be incompatible by virtue of their functionality or structure. Unless contrary to physical possibility, it is contemplated that: i) the methods / steps described herein can be performed in any order and / or in any combination; and (ii) the components of the various embodiments can be combined in any manner.

[0142] Although the subject matter has been described in language specific to structural features and / or behavior, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or behaviors described above. Rather, the specific features and behaviors described above are disclosed as examples of implementing the claims, and other equivalent features and behaviors are also intended to be within the scope of the claims.

[0143] In the preceding description, numerous specific details have been described with reference to embodiments, which may vary from implementation to implementation. Therefore, the specification and drawings should be considered illustrative, not restrictive. The sole and exclusive indication of the scope of the embodiments, and what the applicant expects to be the scope of the embodiments, is the literal and equivalent scope of the claims published from this application in the specific form of the published claims, including any subsequent amendments. Any definitions of terms expressly set forth herein for inclusion in such claims should be taken as meaning as such terms are used in the claims. Furthermore, when the term “comprising” is used in the preceding specification or appended claims, what follows that phrase may be an additional step or entity, or a sub-step / sub-entity of a previously stated step or entity.

Claims

1. A crypto asset custody system, comprising: The server computer is configured as follows: The system transmits an endorsement request for a crypto-asset transaction to be conducted on the blockchain by the server computer. This endorsement request is then transmitted to a user device associated with the user, prompting the user device to sign the crypto-endorsement of the crypto-asset transaction using the private key associated with the user device. Receive multiple data points collected from one or more mobile devices communicating with the user device, the multiple data points including i) multiple biometric data points associated with different biometric categories and ii) the amount of the crypto asset transaction, and Receive the cryptographic endorsement of the cryptographic asset transaction from the user device; The risk analysis module communicates with the server computer and is configured to: Each of the multiple biometric data points is compared with the corresponding historical trend among the multiple historical trends generated by the risk analysis module, wherein the biometric data points being compared with each other and the corresponding historical trends are associated with the same biometric category. as well as A risk metric is generated based at least on a comparison of each of the plurality of data points with a corresponding historical trend among the plurality of historical trends. The risk metric represents the risk of accepting cryptographic endorsement of the crypto asset transaction from the user device according to a strategy retrieved from a vault associated with the crypto asset transaction. as well as A hardware security module, which communicates with the server computer and the risk analysis module, is configured to apply a cryptographic digital signature to the cryptographic asset transaction using a cryptographic key stored only in a secure storage device of the hardware security module, based on the generated risk metric associated with the cryptographic endorsement. The cryptographic key cannot be accessed by devices outside the hardware security module, which include at least the user device, the server computer, and the risk analysis module.

2. The encrypted asset custody system according to claim 1, wherein, The hardware security module communicates with the server computer via a relay server and is configured to: In response to the risk metric falling below a threshold risk metric, the cryptographic endorsement of the crypto asset transaction is received from the server computer via the relay server, and Generate the cryptographic key associated with the crypto asset transaction and capable of controlling access to the blockchain.

3. The encrypted asset custody system according to claim 1, wherein, The risk analysis module is also configured to: Prior to receiving the plurality of data points, one or more mobile devices are registered on the encrypted asset custody system. The registration of each mobile device is performed in response to receiving a registration request from the user device using the server computer. The registration request is used to associate a user with one or more mobile devices.

4. The encrypted asset custody system according to claim 3, wherein, Registration of each mobile device includes assigning necessary or unnecessary conditions to each mobile device, such that specific data points are collected from each of the one or more mobile devices, wherein at least one of the one or more mobile devices is assigned the necessary condition.

5. The encrypted asset custody system according to claim 1, wherein, The risk analysis module is also configured to: Generate graphical visualizations including the aforementioned historical trends; and The expected value of the multiple data points is determined based on the multiple historical trends.

6. A method using a crypto-asset custody system, the crypto-asset custody system comprising a server computer, a hardware security module communicating with the server computer, and a risk analysis module, the risk analysis module communicating with the server computer and the hardware security module, the method comprising: Using the server computer, an endorsement request for a crypto asset transaction to be performed by the server computer is transmitted to a user device associated with the user. The endorsement request is configured to prompt the user device to sign the cryptographic endorsement of the crypto asset transaction using a private key associated with the user device. Using the server computer, multiple data points collected from one or more mobile devices communicating with the user device are received, the multiple data points including i) multiple biometric data points associated with different biometric categories and ii) the amount of the crypto asset transaction; Using the server computer, the encrypted endorsement of the encrypted asset transaction is received from the user device; Using the risk analysis module, each of the multiple biometric data points is compared with the corresponding historical trend among the multiple historical trends generated by the risk analysis module, wherein the biometric data points being compared with each other and the corresponding historical trends are associated with the same biometric category. Using the risk analysis module, a risk metric is generated based at least on a comparison of each of the plurality of data points with the corresponding historical trend among the plurality of historical trends. The risk metric represents the risk of accepting the crypto endorsement from the user device according to a strategy retrieved from a vault associated with the crypto asset transaction. as well as Using the hardware security module and an encryption key stored only in the secure storage device of the hardware security module, a cryptographic digital signature is applied to the cryptographic asset transaction based on the risk metric generated and associated with the cryptographic endorsement. The encryption key cannot be accessed by devices outside the hardware security module. The devices outside the hardware security module include at least the user device, the server computer, and the risk analysis module.

7. The method according to claim 6, wherein, The hardware security module communicates with the server computer via a relay server, and the method further includes: In response to the risk metric falling below a threshold risk metric, the cryptographic endorsement is transmitted from the server computer to the hardware security module via a relay server; and The hardware security module is used to generate the encryption key associated with the encrypted asset transaction and capable of controlling access to the blockchain.

8. The method according to claim 6, further comprising: Using the risk analysis module, one or more mobile devices are registered before the plurality of data points are received. The registration of each mobile device is performed in response to a registration request received from the user device using the server computer. The registration request is used to associate the user with the one or more mobile devices.

9. The method according to claim 8, wherein, The registration of each mobile device includes: using the risk analysis module of the encrypted asset custody system to assign necessary or unnecessary conditions to each of the one or more mobile devices, so as to collect specific data points from each of the one or more mobile devices, wherein at least one of the one or more mobile devices is assigned the necessary condition.

10. The method according to claim 6, wherein, The mobile device in one or more mobile devices is the user's smartwatch or fitness tracker, and The plurality of data points include the geographic location of the smartwatch or the fitness tracker as measured by the GPS receiver of the smartwatch or the fitness tracker.

11. The method according to claim 6, wherein, The plurality of data points includes at least one of the following: The identification number of the mobile device in one or more mobile devices; The height of the mobile device relative to sea level, as measured by the mobile device itself; The service set identifier of the wireless network to which the mobile device is connected; as well as The Bluetooth device address of the mobile device.

12. The method of claim 6, further comprising: Using the risk analysis module, a mismatch is detected between a first data point and a second data point among the plurality of data points, wherein the first data point is collected from a first mobile device among the one or more mobile devices, and the second data point is collected from a second mobile device among the one or more mobile devices. as well as Using the risk analysis module, the risk metric is updated in response to the detection of the mismatch.

13. The method of claim 6, further comprising generating a graphical visualization of the risk measure by: Using the risk analysis module, feature vectors are extracted based on the multiple data points; and The risk analysis module is used to generate the risk metric based at least on the feature vector. The risk analysis module is trained using machine learning to represent the risk of accepting the cryptographic endorsement based on whether the plurality of data points match the expected values ​​of the plurality of data points.

14. A non-transitory computer-readable storage medium for storing instructions executable by a crypto-asset custody system, the crypto-asset custody system comprising a server computer, a hardware security module, and a risk analysis module, wherein the instructions, when executed by the crypto-asset custody system, cause the crypto-asset custody system to perform the following operations: Using the server computer of the crypto asset custody system, an endorsement request for a crypto asset transaction to be carried out is transmitted to a user device. The endorsement request is configured to prompt the user device to sign the crypto endorsement of the crypto asset transaction using the private key associated with the user device. Using the server computer, multiple data points collected from one or more mobile devices communicating with the user device are received, the multiple data points including i) multiple biometric data points associated with different biometric categories and ii) the amount of the crypto asset transaction; Using the server computer, the encrypted endorsement of the encrypted asset transaction is received from the user device; Using the risk analysis module, each of the multiple biometric data points is compared with the corresponding historical trend among the multiple historical trends generated by the risk analysis module, wherein the biometric data points being compared with each other and the corresponding historical trends are associated with the same biometric category. Using the risk analysis module, a risk metric is generated based at least on a comparison of each of the plurality of data points with the corresponding historical trend among the plurality of historical trends. The risk metric represents the risk of accepting the crypto endorsement from the user device according to a strategy retrieved from a vault associated with the crypto asset transaction. as well as Using the hardware security module and an encryption key stored only in the secure storage device of the hardware security module, a cryptographic digital signature is applied to the cryptographic asset transaction based on the risk metric generated and associated with the cryptographic endorsement. The encryption key cannot be accessed by devices outside the hardware security module. The devices outside the hardware security module include at least the user device, the server computer, and the risk analysis module.

15. The non-transitory computer-readable storage medium according to claim 14, wherein, The instruction also causes the hardware security module to perform the following operations: In response to the risk metric falling below a threshold risk metric, a key derivation function is used to generate the cryptographic key associated with the cryptographic asset transaction.

16. The non-transitory computer-readable storage medium according to claim 14, wherein, The instruction also causes the risk analysis module to perform the following operations: Before receiving the plurality of data points, one or more mobile devices are registered in response to receiving a registration request from the user device, the registration request being used to associate the user with the one or more mobile devices.

17. The non-transitory computer-readable storage medium according to claim 16, wherein, Registering one or more mobile devices includes: using the risk analysis module of the encrypted asset custody system to assign necessary or unnecessary conditions to each of the one or more mobile devices, so as to collect specific data points from each of the one or more mobile devices, wherein at least one of the one or more mobile devices is assigned the necessary condition.

18. The non-transitory computer-readable storage medium according to claim 14, wherein, The mobile device in one or more mobile devices is the user's smartwatch or fitness tracker, and The plurality of data points include the geographic location of the smartwatch or the fitness tracker as measured by the GPS receiver of the smartwatch or the fitness tracker.

19. The non-transitory computer-readable storage medium according to claim 14, wherein, The plurality of data points includes at least one of the following: The identification number of the mobile device in one or more mobile devices; The height of the mobile device relative to sea level, as measured by the mobile device itself; The service set identifier of the wireless network to which the mobile device is connected; as well as The Bluetooth device address of the mobile device.

20. The non-transitory computer-readable storage medium according to claim 14, wherein, The instruction also causes the risk analysis module to perform the following operations: A mismatch is detected between a first data point and a second data point among the plurality of data points, wherein the first data point is collected from a first mobile device among the one or more mobile devices, and the second data point is collected from a second mobile device among the one or more mobile devices. as well as The risk metric is updated in response to the detection of the mismatch.

21. A computer program product comprising a program that causes a computer to perform the method according to any one of claims 6 to 13.

Images