OFFLINE CRYPTOCURRENCY WALLET WITH SECURE KEY MANAGEMENT

A method of performing cryptocurrency transactions requiring a private key includes: establishing a connection from a smart wallet to a user device; receiving a transaction request requiring the private key; disabling the connection; retrieving the private key to a private key memory; processing the transaction; clearing the private key memory; enabling the connection; and sending a completion message. A method of performing cryptocurrency transactions requiring a private key includes: establishing a connection from a user device to a smart wallet; receiving a transaction request requiring the private key; sending the transaction request to the smart wallet; determining that the smart wallet is disconnected from the user device; waiting for the smart wallet to reconnect; and receiving a response from the smart wallet. A smart wallet includes: a storage; a private key storage; and a communication module that is able to communicate with a user device across at least one channel.

BACKGROUND

Many consumers utilize cryptocurrency to facilitate various financial transactions. Each consumer may be associated with a “wallet” that manages each cryptocurrency account. Such management may include, for instance, logging of transactions, maintaining balance information, etc.

Such wallets may typically utilize a private and public key pair. The public key may allow others to send cryptocurrency to the user associated with the public key. The private key may allow the user associated with the private key to send cryptocurrency to others.

Wallets associated with such cryptocurrency accounts may be “online” or “offline”. Online (or “hot”) wallets may generate public and private key pairs at some online entity for use in users' wallets. Such online entities may be a target for hackers as access to many account associated with many users may be achieved. Offline (or “cold”) wallets may generate public and private key pairs at an offline (i.e., unconnected) device, where the private key is retained at the offline device. Such an approach limits the

While offline wallets are not prime hacking targets, because each wallet must be individually accessed via a dedicated hardware device rather than a common resource shared by many accounts. In addition, offline wallets typically require physical access to a hardware device in order to hack an account.

Although offline wallets offer security benefits, backup and/or restore operations are cumbersome. Thus, many users may fail to take such steps and risk losing all cryptocurrency in an account if a wallet device is lost or damaged and the backup and/or restore is unsuccessful or incomplete. Typical existing solutions may display a set of phrases (e.g., twenty-four phrases) in a specified order, where users are required to provide the set of phrases in the specified order to restore a private key. Many, most, or all users may fail to properly document such phrases or other restoration criteria.

Furthermore, even if a user fulfills such requirements (e.g., by tabulating, printing, photographing, etc.) the list of phrases, backup and/or restore operations may not be secure, as the group of seed phrases are shown in unencrypted plain text format. Thus, users may fail to properly lock up, encrypt, and/or otherwise secure such recovery information. In addition, any entity that attains the list of phrases is able to restore a private key.

In addition, even “offline” wallets may require connection via a device (e.g., a personal computer, smartphone, etc.) that may expose private key information when processing cryptocurrency transactions. Existing secure solutions are cumbersome, and require users to manually enter or capture transaction information to the wallet via a keyboard, touchscreen, camera, etc.

Therefore there exists a need for secure, automated transaction processing via cryptocurrency wallets without exposing private key information.

SUMMARY

Some embodiments may provide a smart wallet device and a smart key device for use with cryptocurrency systems.

The smart wallet device may include various physical connectors that may allow the smart wallet to interact with the smart key device and/or various user devices (e.g., smartphones, tablets, personal computers, etc.). In addition, the smart wallet device may include displays and/or other user interface elements that may provide authentication information (and/or other information) to a user associated with the smart wallet device. The smart wallet device may further include various input elements (e.g., buttons, keys, touchscreens, etc.) that may be able to receive user inputs. The smart wallet device may include a local storage that is able to store various public and private encryption keys that may be used for authentication of cryptocurrency transactions.

The smart wallet may be associated with a personal identification number (PIN) or passcode that is set by a user. The PIN may be required to be entered (and validated) at the wallet in order to unlock the wallet such that transactions may be processed via the wallet.

The smart key device may include various physical connectors that may allow the smart key device to interact with the smart wallet device. In addition, the smart key device may include a local storage that may be able to store various public and private encryption keys. The local storage may be at least partly controlled by a state of the smart key device. In an unlocked state, data may be written to the local storage, while in a locked state, the local storage may be read only.

The smart wallet device may be able to provide and/or generate various public and private key pairs including a wallet key pair (a private wallet key and a public wallet key) and a transaction key pair (a private transaction key and a public transaction key).

The smart key device may be able to provide and/or generate a key device key pair (a private key device key and a public key device key).

During backup, the smart wallet device may encrypt the private transaction key and PIN using the public key device key and send the encrypted key and PIN to the smart key device. The smart key device may decrypt the encrypted key and PIN using the private key device key, encrypt the private transaction key and PIN using the public wallet key, and store the encrypted key and PIN.

During restore, the smart wallet may retrieve the encrypted key and PIN (encrypted using the public wallet key) and decrypt the key and PIN using the private wallet key in order to restore the unencrypted private transaction key and PIN.

When processing transactions that require the private key, the smart wallet may disconnect from any other devices (e.g., a user device) when accessing and/or utilizing the private key. The private key may be placed in a dedicated memory or memory location. Such memory may be wiped or cleared after using the private key. The smart wallet may then reconnect to the user device in order to complete the transaction. Such an approach ensures that the private key is not accessible when the smart wallet is connected to any other device and is thus not exposed.

The preceding Summary is intended to serve as a brief introduction to various features of some exemplary embodiments. Other embodiments may be implemented in other specific forms without departing from the scope of the disclosure.

DETAILED DESCRIPTION

The following detailed description describes currently contemplated modes of carrying out exemplary embodiments. The description is not to be taken in a limiting sense, but is made merely for the purpose of illustrating the general principles of some embodiments, as the scope of the disclosure is best defined by the appended claims.

Various features are described below that can each be used independently of one another or in combination with other features. Broadly, some embodiments generally provide a smart cryptocurrency wallet device that is able to process transactions without exposing private key information.

A first exemplary embodiment may provide a method of performing cryptocurrency transactions requiring a private key, the method comprising: establishing a connection from a smart wallet device to a user device; receiving, at the smart wallet device, a transaction request requiring the private key; disabling the connection; retrieving the private key to a private key memory; processing the transaction; clearing the private key memory; enabling the connection; and sending a completion message from the smart wallet device to the user device. The transaction request may include information such as a transaction amount, type of cryptocurrency, receipt address, etc.

A second exemplary embodiment may provide a method of performing cryptocurrency transactions requiring a private key, the method comprising: establishing a connection from a user device to a smart wallet device; receiving, at the user device, a transaction request requiring the private key; sending the transaction request to the smart wallet device; determining that the smart wallet device is disconnected from the user device; waiting for the smart wallet device to reconnect; and receiving a response from the smart wallet device. The transaction request may include information such as a transaction amount, type of cryptocurrency, receipt address, etc.

A third exemplary embodiment may provide a smart cryptocurrency wallet device comprising: a local storage; a private key storage; and a communication module that is able to communicate with a user device across at least one channel.

Several more detailed embodiments are described in the sections below. Section I provides a description of a system architecture used by some embodiments. Section II then describes various methods of operation implemented by some embodiments. Lastly, Section III describes a computer system which implements some of the embodiments.

I. System Architecture

FIG. 1illustrates a schematic block diagram of a secure wallet system100according to an exemplary embodiment. As shown, the system100may include a smart wallet110, a smart key120, a wallet server130, a retail server140, a user device150, and a set of networks160.

Each smart wallet110may be a computing device able to store and process data. The smart wallet may be associated with one or more cryptocurrency accounts. The smart wallet may allow secure cryptocurrency transactions through the use of private and public key pairs. The smart wallet may be able to generate a public and private key pair. The smart wallet may be able to interact with the smart key120and various user devices150, as appropriate, via one or more physical connections (e.g., a “key interface”). The smart wallet110may an offline smart wallet that is not connected to the network160. The smart wallet110may receive firmware updates from a server130associated with the wallet service.

In some embodiments, the smart wallet110may include various user interface features (e.g., displays, speakers, etc.) such that the wallet is able to provide authentication information (and/or other information such as user prompts) as needed. For instance, the wallet may display a changing key that is synchronized to a wallet server130such that a user may be able to validate a transaction by supplying the key displayed at the wallet110. Alternatively, such information may be provided automatically via the user device150such that the wallet server130and/or retail server140receive appropriate transaction confirmation. In addition, the wallet may include various user interface elements that may allow a user to select various modes, options, etc. Such elements may include, for instance, buttons, keypads, touchscreens, microphones, etc.

Each smart key120may be an electronic device capable of storing and/or processing data. The smart key may have a locking feature such that the key is able to change from an unlocked state to a locked state after a private key is provided by the smart wallet110. When the key120is changed to a locked state, the device may become read-only such that the key is not able to be modified. In addition, the locked state may include a permanent modification such that the smart key is not able to transition back to an unlocked state after initially being locked. The smart key may be able to generate a public and private key pair. The smart key may be able to interact with the smart wallet110. Such interaction may be limited to a physical connection (e.g., a universal serial bus or “USB” connection).

Each wallet server130(and/or collection of servers) may be an electronic device that is able to execute instructions and/or otherwise process data. The server may specifically facilitate cryptocurrency transactions associated with the smart wallet110account. The server may be accessed via an application programming interface (API) and/or other appropriate resource. The server130may be associated with a particular cryptocurrency service or technology.

Each retail server140and/or other third-party resource may be able to interact with the wallet server130, user device150, and/or other appropriate elements in order to administer various cryptocurrency transactions. The server140may be able to interact with various cryptocurrency services or technologies.

Each user device150may be an electronic device able to execute instructions and/or otherwise process data. The user device may include various user interface elements that may allow user interaction. The user device may be a device such as a smartphone, tablet, personal computer, television, wearable device, etc.

The networks160may include various wired and/or wireless communication pathways among the various system elements. Such networks may include, for instance, Ethernet, Wi-Fi, cellular, Bluetooth, the Internet, etc.

During operation, a user may utilize the user device150(via one or more applications, web browsers, etc.) to initiate and/or react to a cryptocurrency event. Such events may include, for instance, sending an invoice, receiving payments, delivering payment, authorizing a debit, etc. The event may require private key validation (e.g., as when funds are removed from the user's account). Such an event may prompt the user to enter private key encoded information (e.g., by entering a PIN or passcode via wallet110). The private key encoded information may be provided by the smart wallet. The wallet server130may validate the private key encoded information and process the transaction (or reject the transaction as appropriate).

FIG. 2illustrates a schematic block diagram of a smart wallet device110and smart key device120included in the system100. The wallet110and key120may be paired devices that are specifically associated to each other (e.g., via matching or associated keys, protocols, etc.). As shown, the smart wallet110may include a wallet private key210, a wallet public key220, an authentication module230, a private key240, and a public key250. The smart key may include a key private key260, a key public key270, an authentication module280, a state lock290, and a recovery key295. In addition, the smart wallet110may include a copy of the smart key public key270and the smart key120may include a copy of the wallet public key220. Each device may further include various appropriate elements omitted for clarity and brevity (e.g., power sources, user interface elements, storages, etc.).

The wallet private key210may be paired to the wallet public key220. The wallet private key210may not be shared to any other resource, while the wallet public key220may be freely distributed to other resources. The keys210and220may be provided and/or generated by the smart wallet110. As described above, the public key220may be used for encryption while the private key210may be used for decryption. The wallet key pair210-220and key public key270may be used for secure communication between the wallet110and the smart key120. Some embodiments may utilize other secure protocols, such as advanced encryption standard (AES). The wallet key pair210-220and key public key270may be preloaded into the firmware of the wallet110, as indicated by the fill pattern.

The wallet authentication module230may include information associated with various authentication protocols. For instance, such information may include handshake information such as validation criteria, lists of elements, etc. The module230may be able to interact with the smart key120in order to validate the smart key and/or smart wallet110information.

The private key (or “private transaction key”)240may be paired to the public key (or “public transaction key”)250. The private key240may not be shared to any other resource, while the public key250may be freely distributed to other resources. The keys240and250may be generated by the smart wallet110. As described above, the public key250may be used for wallet deposits while the private key240may be used for payments with the cryptocurrency system associated with the wallet110. The key pair240-250may be used for secure cryptocurrency transactions. Any stored version of the private key240may have been previously encrypted using the wallet public key220and/or other encryption protocols or algorithms.

The key private key260may be paired to the key public key270. The key private key260may not be shared to any other resource, while the key public key270may be freely distributed to other resources. The keys260and270may be provided and/or generated by the smart key120. As described above, the public key270may be used for encryption while the private key260may be used for decryption. The key pair260-270associated with the smart key120and the wallet public key220may be used for secure communication between the wallet110and the smart key120. The key pair260-270associated with the smart key120and the wallet public key220may be preloaded into firmware of the smart key120, as indicated by the fill pattern.

The key authentication module280may include information associated with various authentication protocols. For instance, such information may include handshake information such as validation criteria, lists of elements, etc. The module280may be able to interact with the smart wallet110in order to validate the smart wallet and/or smart key120information.

The state lock290may be able to permanently fix the memory of the smart key such that the device is not writable after initially saving a recovery key295. The state lock290may also be able to provide an indication to the smart wallet as to the current state of the key120(i.e., “locked” or “unlocked”).

The recovery key295may be an encrypted version of the private key240that is able to be used to recover the unencrypted private key240to the wallet110.

FIG. 3illustrates a schematic block diagram of an offline smart wallet system300of some embodiments. As shown, the system may include a smart wallet110, a user device150, a wallet server130, and/or a retail server140. This system is referred to as an “offline” system, even though the user device150may be a network-connected device, because the wallet does not include online connectivity (e.g., a network connection to either server130or140).

The smart wallet110may include a controller310, a storage320, a private storage330, a communication module340, a transmitter/receiver350, and a physical interface360. The user device may include a communication interface370, a wallet application380, and/or a browser390.

The controller310may be an electronic device that is able to execute instructions and/or otherwise process data. The controller may be able to at least partly direct operations of other device elements.

The storage320may be an electronic device capable of storing data and/or instructions. The private storage330may be a separate device or a specified region of storage320. The private storage330may be “wiped” (i.e., cleared and/or written with random data) whenever the smart wallet110is connected to a user device150such that private key data is not exposed outside the wallet. Either or both storages320-330may be embedded in the controller310in some embodiments.

The communication module340may be able to direct interactions with the user device150via the wireless resources350and/or physical connection interface(s)360. The communication module340may be able to completely disable the resources350and360(e.g., by removing power supplied to those elements) such that no external communication is possible. In some embodiments, the communication module340may be embedded in the controller310.

The transmitter/receiver350may be able to communicate across various appropriate wireless channels (e.g., Bluetooth, Wi-Fi, etc.).

The physical interface360may be able to communicate across various physical connections (e.g., a USB connection).

The communication interface370may be able to communicate with the smart wallet110using various wired and/or wireless communication resources.

The wallet application380may be a dedicated application associated with a particular cryptocurrency (or set of cryptocurrencies) and/or with the smart wallet110. Such an application380may allow a user to perform various transactions (e.g., send money, receive money, etc.).

The browser390may allow users to connect to the smart wallet110without needing a dedicated application380. In some embodiments, however, the communication interface370may use a proprietary protocol when communicating with the transmitter/receiver350or physical interface360, where such a proprietary protocol is implemented by the wallet application380.

One of ordinary skill in the art will recognize that systems100and300may be implemented in various different ways without departing from the scope of the disclosure. For instance, different embodiments may include different numbers of instantiations of each system element or device (e.g., the system may include multiple servers, wallets, etc.). As another example, the components may have various other communication pathways than shown. Further, various additional components may be included and/or various listed components may be omitted.

II. Methods of Operation

FIG. 4illustrates a flow chart of an exemplary process400that generates a private wallet key used by the system100. Such a process may be executed by the smart wallet110of some embodiments. The smart key120may execute a complementary process, such as process500. Process400may begin, for instance, when a user activates a smart wallet110of some embodiments.

As shown, the process may receive (at410) a personal identification number (PIN) or passcode. The PIN may be encrypted and stored at the wallet (e.g., at authentication module230). A user may be required to entire the PIN in order to authenticate transactions performed via the wallet.

Next, the process may retrieve (at420) one or more keys and/or key pairs (e.g., pair210-220, key public key270). Such key pairs may be generated in various appropriate ways, using various appropriate algorithms. The keys and/or key pairs may be pre-loaded into firmware of the wallet110. The process may encrypt and store the private key240(e.g., using the key public key270) at a local storage of the smart wallet110.

The process may generate (at43) one or more key pairs (e.g., pair240-250) at the wallet110. Such key pairs may be generated in various appropriate ways, using various appropriate algorithms.

The process may then generate (at440) a backup prompt. The backup prompt may utilize various user interface elements of the wallet (e.g., a display screen) to indicate that the smart key120should be connected to the smart wallet110(e.g., by providing a message such as “connect key to wallet”). Such a connection may be made via USB or other appropriate physical interface. The process may be able to automatically detect that a key120has been connected to the wallet110.

Process400may then determine (at450) whether a handshake or other authentication criteria have been satisfied. If the process determines (at450) that the criteria have not been satisfied, the process may reset (at460) the wallet and then may end. Such a reset may include resetting state information (and/or other information) associated with the wallet110and/or key120such that the process may be restarted.

During the handshake (and/or other appropriate times), the key120may send the key public key270to the wallet110(and/or the wallet may retrieve the key public key270). Likewise, the wallet110may send the wallet public key220to the smart key device120(and/or the key device may retrieve the wallet public key220). Alternatively, as described above, the keys270and220may be pre-loaded into the firmware of both devices110and120.

If the process determines (at450) that the handshake was successful, the process may determine (at470) whether the smart key120is in an unlocked state. Such a determination may be made by retrieving state lock data290from the key120. If the process determines (at470) that the key120is not unlocked (i.e., that the key was previously used for backup), the process may end. Operations450and470may together provide “authentication” of a smart key120that is physically connected to the wallet110.

If the process determines (at470) that the key120is in an unlocked state, the process may encrypt (at480) the private key240using the key public key270, send (at490) the encrypted key295to the smart key device120and then may end. In addition, the PIN or passcode may be encrypted and sent to the smart key device120In addition to the encrypted key, the process may send the wallet public key220to the smart key device120.

In some embodiments, process400may verify that the encrypted key was successfully received by determining that the state of the smart key device120has changed to “locked” within a specified time. After verification of the state change, the process may provide an indication via the wallet user interface elements (e.g., by displaying a message such as “backup complete”).

FIG. 5illustrates a flow chart of an exemplary process500that stores the private wallet key at a smart key device120used by the system100. Such a process may be executed by the smart key120of some embodiments. The smart wallet110may execute a complementary process, such as process400. Process500may begin, for instance, when a smart key120is connected to a smart wallet110.

As shown, the process may determine (at510) whether the handshake or other authentication criteria have been satisfied. If the process determines (at510) that the handshake has not been successful, the process may end.

If the process determines (at510) that the handshake was successful, the process may determine (at520) whether the smart key120is locked. Such a determination may be made by retrieving state lock data290stored at the key120. If the process determines (at520) that the smart key120is not unlocked, the process may end.

If the process determines (at520) that the smart key120is unlocked, the process may receive (at530) the encrypted key provided by the wallet110at370, where the encrypted key was encrypted with key public key270. Likewise, the encrypted PIN or passcode may also be received at the smart key120.

Next, process500may decrypt (at540) the received key using the smart key private key260. The process may then encrypt (at550) using the smart wallet public key220.

Process500may then store (at560) the encrypted key295at internal storage of the smart key device120. Finally, the process may transition (at570) to the locked state and then may end.

As described above, the process may further send a confirmation to the wallet110in some embodiments.

After performing the key backup, a user may install various wallet applications (and/or access such applications via a resource such as a web browser) to a user device150that may utilize data provided by the smart wallet110.

FIG. 6illustrates a flow chart of an exemplary process600that restores a private wallet key from a smart key device120to a smart wallet device110used by the system100. Such a process may be executed by the smart wallet110of some embodiments. The smart key120may execute a complementary process. Process600may begin, for instance, when a user initiates a restore operation using a smart wallet110of some embodiments.

As shown, the process may generate (at610) a restore prompt. Such a prompt may include a display of an appropriate message (“insert smart key”). Next, the process determines (at620) whether the handshake has been satisfied. If the process determines (at620) that the handshake has not been satisfied, the process may end.

If process600determines (at620) that the handshake has been satisfied, the process may determine (at630) whether the smart key device is in a locked state. If the process determines (at630) that the smart key is not locked, the process may end.

If the process determines (at630) that the smart key120is in a locked state, the process may retrieve (at640), at the wallet110, the encrypted key295stored in the local storage of the smart key120. In addition, the encrypted PIN or passcode may also be retrieved.

Next, the process may decrypt (at650), at the wallet110, the encrypted key using the wallet private key210. The process may then encrypt (e.g., using key public key270) and store (at660) the decrypted private key240at the wallet110and then may end.

FIG. 7illustrates a flow chart of an exemplary process700that facilitates secure wallet transactions using the system100. Such a process may be executed by the smart wallet110of some embodiments. The user device150may execute a complementary process (e.g., process800). Process700may begin, for instance, when a user connects a user device150to a smart wallet110of some embodiments and initiates a cryptocurrency transaction. Such connection may involve various authentication algorithms (e.g., a handshake, verification of user information, etc.), while the transaction may include receipt of funds, withdrawal of funds, etc. related to a purchase, sale, or other appropriate transaction.

As shown, the process may determine (at710) whether a private key is required for the requested transaction. Typically, withdrawals may require a private key while deposits may not. If the process determines (at710) that a private key is not required, the process may process (at720) the transaction. Such processing may involve various calculations, decryptions, encryptions, etc. Next, the process may complete (at730) the transaction and then may end. Transaction completion may involve different elements depending on the particular transaction scenario. For instance, accepting a deposit may require a confirmation message or the like. In some cases, a deposit or similar transaction may be processed at the smart wallet and the transaction completion may include a simple message indicating receipt of the transfer request.

If the process determines (at710) that the private key is required for the requested transaction, the process may disable (at740) the user device connection. Such disablement may include sending a message or command to the communication module340, transmitter/receiver350, and/or the physical interface360. In some cases, disablement may include gating (i.e., removing) power to the appropriate resource such that communication is not possible over the channel. In this way, the private key is not exposed during use.

Next, the process may retrieve (at750) the private key240previously encrypted with the wallet public key220(and/or other encryption protocols or algorithms) and stored at the wallet110. The process may then decrypt (at760) the private key240using the wallet private key210.

Next, the process may process (at770) the requested transaction. As above, such processing may involve various calculations, decryptions, encryptions, etc. In this case, at least some such actions require use of the private key240.

The process may then clear (at780) the private key memory330. Such clearing may include deleting stored data, storing random data, and/or other appropriate actions that prevent exposure of the private key240. In some embodiments, the private key memory330may be able to be disabled (e.g., by gating power) such that the memory is not accessible or returns a default value.

Next, the process may enable (at790) the user device connection. Such enablement may involve, for example, powering on the transmitter350and/or physical interface360.

Process700may then complete (at730) the requested transaction by sending a completion message to the user device150and then may end. Such a completion message may include one or more values calculated and/or accessed using the private key240. The user device150may then relay such information to an appropriate online resource such as a wallet server130, retail server140, etc.

Although process700has been described with respect to a user device connection, one of ordinary skill in the art will recognize that a similar process may be used to allow the wallet to connect to various other resources (e.g., a server).

FIG. 8illustrates a flow chart of an exemplary user device process800that facilitates secure wallet transactions using the system100. Such a process may be executed by a user device150of some embodiments. A smart wallet110may execute a complementary process (e.g., process700). Process800may begin, for instance, when a user launches a wallet application of some embodiments at a user device150(and/or otherwise connects to a cryptocurrency resource). Such launch or connection may involve various authentication algorithms (e.g., a handshake, verification of user information, etc.).

As shown, the process may retrieve (at810) account information. Such information may include, for instance, identification of a wallet service, user identity information, authentication information, etc. Next, the process may connect (at820) to the smart wallet110of some embodiments. Such a connection may be wired or wireless, as appropriate.

Next, the process may determine (at830) whether a transaction request has been received. Such a determination may be made in various appropriate ways based on various appropriate criteria. For instance, a user may initiate a purchase at a retail site, which may send a withdrawal request. As another example, a user may initiate a subscription or installment payment using an application of some embodiments.

If the process determines (at830) that no transaction request has been received, the process may repeat operation830until the process determines (at830) that a transaction request has been received. If the process determines (at830) that a transaction request has been received, the process may connect (at840) to a wallet server130of some embodiments.

Next, the process may send (at850) a transaction request to the smart wallet110of some embodiments. Such a request may include, for instance, a transaction type (e.g., deposit, withdrawal, etc.), cryptocurrency type, transaction amount, recipient address (and/or other appropriate identifying information), and/or other appropriate information (e.g., description, quantities, etc.).

Process800may then determine (at860) whether a private key is required to process the transaction. As discussed about, a private key may typically be required to withdraw funds from the wallet.

If the process determines (at860) that a private key is required, the process may expect the smart wallet to disable any communication connection and then may determine (at870) whether the wallet has reconnected to the user device. The process may repeat operation870(e.g., at regular intervals) until the process determines (at870) that the wallet has reconnected (in some embodiments, the process may end if a response timeout period is exceeded).

After the process determines (at870) that the smart wallet is reconnected, or after determining (at860) that the private key is not required, the process may receive (at880) a response from the smart wallet. In some embodiments, the received response may indicate that the wallet is reconnected. The response may include various calculations and/or other information related to transaction completion.

After receiving (at880) the response, the process may send (at890) a completion message to the appropriate resource (e.g., server130or140) and then may end. The completion message may include calculated values, keys, and/or other appropriate information.

One of ordinary skill in the art will recognize that processes400-800may be implemented in various different ways without departing from the scope of the disclosure. For instance, each process may include additional operations and/or omit various listed operations. The operations may be performed in different orders, iteratively, and/or based on some criteria. Each process may be divided into multiple sub-processes and/or combined into a macro process.

III. Computer System

Many of the processes and modules described above may be implemented as software processes that are specified as one or more sets of instructions recorded on a non-transitory storage medium. When these instructions are executed by one or more computational element(s) (e.g., microprocessors, microcontrollers, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc.) the instructions cause the computational element(s) to perform actions specified in the instructions.

In some embodiments, various processes and modules described above may be implemented completely using electronic circuitry that may include various sets of devices or elements (e.g., sensors, logic gates, analog to digital converters, digital to analog converters, comparators, etc.). Such circuitry may be able to perform functions and/or features that may be associated with various software elements described throughout.

FIG. 9illustrates a schematic block diagram of an exemplary computer system900used to implement some embodiments. For example, the system described above in reference toFIG. 1may be at least partially implemented using computer system900. As another example, the processes described in reference toFIG. 4-FIG. 8may be at least partially implemented using sets of instructions that are executed using computer system900.

Computer system900may be implemented using various appropriate devices. For instance, the computer system may be implemented using one or more personal computers (PCs), servers, mobile devices (e.g., a smartphone), tablet devices, and/or any other appropriate devices. The various devices may work alone (e.g., the computer system may be implemented as a single PC) or in conjunction (e.g., some components of the computer system may be provided by a mobile device while other components are provided by a tablet device).

As shown, computer system900may include at least one communication bus905, one or more processors910, a system memory915, a read-only memory (ROM)920, permanent storage devices925, input devices930, output devices935, audio processors940, video processors945, various other components950, and one or more network interfaces955.

Bus905represents all communication pathways among the elements of computer system900. Such pathways may include wired, wireless, optical, and/or other appropriate communication pathways. For example, input devices930and/or output devices935may be coupled to the system900using a wireless connection protocol or system.

The processor910may, in order to execute the processes of some embodiments, retrieve instructions to execute and/or data to process from components such as system memory915, ROM920, and permanent storage device925. Such instructions and data may be passed over bus905.

System memory915may be a volatile read-and-write memory, such as a random access memory (RAM). The system memory may store some of the instructions and data that the processor uses at runtime. The sets of instructions and/or data used to implement some embodiments may be stored in the system memory915, the permanent storage device925, and/or the read-only memory920. ROM920may store static data and instructions that may be used by processor910and/or other elements of the computer system.

Permanent storage device925may be a read-and-write memory device. The permanent storage device may be a non-volatile memory unit that stores instructions and data even when computer system900is off or unpowered. Computer system900may use a removable storage device and/or a remote storage device as the permanent storage device.

Input devices930may enable a user to communicate information to the computer system and/or manipulate various operations of the system. The input devices may include keyboards, cursor control devices, audio input devices and/or video input devices. Output devices935may include printers, displays, audio devices, etc. Some or all of the input and/or output devices may be wirelessly or optically connected to the computer system900.

Audio processor940may process and/or generate audio data and/or instructions. The audio processor may be able to receive audio data from an input device930such as a microphone. The audio processor940may be able to provide audio data to output devices940such as a set of speakers. The audio data may include digital information and/or analog signals. The audio processor940may be able to analyze and/or otherwise evaluate audio data (e.g., by determining qualities such as signal to noise ratio, dynamic range, etc.). In addition, the audio processor may perform various audio processing functions (e.g., equalization, compression, etc.).

The video processor945(or graphics processing unit) may process and/or generate video data and/or instructions. The video processor may be able to receive video data from an input device930such as a camera. The video processor945may be able to provide video data to an output device940such as a display. The video data may include digital information and/or analog signals. The video processor945may be able to analyze and/or otherwise evaluate video data (e.g., by determining qualities such as resolution, frame rate, etc.). In addition, the video processor may perform various video processing functions (e.g., contrast adjustment or normalization, color adjustment, etc.). Furthermore, the video processor may be able to render graphic elements and/or video.

Other components950may perform various other functions including providing storage, interfacing with external systems or components, etc.

Finally, as shown inFIG. 9, computer system900may include one or more network interfaces955that are able to connect to one or more networks960. For example, computer system900may be coupled to a web server on the Internet such that a web browser executing on computer system900may interact with the web server as a user interacts with an interface that operates in the web browser. Computer system900may be able to access one or more remote storages970and one or more external components975through the network interface955and network960. The network interface(s)955may include one or more application programming interfaces (APIs) that may allow the computer system900to access remote systems and/or storages and also may allow remote systems and/or storages to access computer system900(or elements thereof).

As used in this specification and any claims of this application, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic devices. These terms exclude people or groups of people. As used in this specification and any claims of this application, the term “non-transitory storage medium” is entirely restricted to tangible, physical objects that store information in a form that is readable by electronic devices. These terms exclude any wireless or other ephemeral signals.

It should be recognized by one of ordinary skill in the art that any or all of the components of computer system900may be used in conjunction with some embodiments. Moreover, one of ordinary skill in the art will appreciate that many other system configurations may also be used in conjunction with some embodiments or components of some embodiments.

In addition, while the examples shown may illustrate many individual modules as separate elements, one of ordinary skill in the art would recognize that these modules may be combined into a single functional block or element. One of ordinary skill in the art would also recognize that a single module may be divided into multiple modules.

The foregoing relates to illustrative details of exemplary embodiments and modifications may be made without departing from the scope of the disclosure as defined by the following claims.