Patent Description:
The book <NPL>) discloses the NetCash system for transferring NetCash E-coins between a buyer and a merchant while the system is online. The NetCash system also supports offline protocols using an extended coin with time windows.

The patent application <CIT> discloses a user computing device in an offline mode. While not being connected to an external network the device transfers a token with an amount of cryptocurrency to a second device.

It would be desirable to provide systems and methods for conducting secure and reliable financial transactions in an offline environment.

According to the independent claim <NUM> a computerized method (<NUM>) is provided for operating a first device (<NUM>) to receive a coin having value from a second device (<NUM>) while the first device (<NUM>) and the second device (<NUM>) are offline or otherwise unable to communicate with a central issuing authority or payment network, the method comprising:
receiving, by the first device (<NUM>), over a local communication channel, information to confirm the validity of the second device (<NUM>), wherein the information to confirm the validity of the second device (<NUM>) includes a hash of application executable code of a wallet application (<NUM>) of the second device (<NUM>), and wherein the validity is confirmed if the first device (<NUM>) can validate the hash of application executable code by generating the same hash using application executable code of a wallet application of the first device (<NUM>); receiving, by the first device (<NUM>), over the local communication channel, a coin transfer message from the second device (<NUM>), the coin transfer message including coin information, wherein the coin information includes a hash generated using a passcode; receiving, by the first device (<NUM>), over a channel other than the local communication channel, the passcode from a user of the second device (<NUM>); verifying, by the first device (<NUM>), information in the coin transfer message by using the passcode to verify the hash included in the coin information; and generating, by the first device (<NUM>), a hash of the coin information using a PIN associated with the first device (<NUM>).

According to the independent claim <NUM> a non-transitory, computer-readable medium storing instructions, that, when executed by a processor of a first device (<NUM>), cause the processor to perform the method.

Particular embodiments of the invention are set out according to the appended dependent claims <NUM>-<NUM>.

Some technical effects of some embodiments of the invention are improved and computerized ways to securely transfer value between users even when no internet or online access is available. With these and other advantages and features that will become hereinafter apparent, a more complete understanding of the nature of the invention can be obtained by referring to the following detailed description and to the drawings appended hereto.

The present invention provides significant technical improvements to interactions requiring the transfer of coins having value between two entities operating computing devices. Pursuant to some embodiments, value may be transferred even in situations where the computing devices are "off-line" (or are otherwise unable to communicate with a central issuing authority or payment network). The present invention is directed to more than merely a computer implementation of a routine or conventional activity previously known in the industry as it significantly advances the technical efficiency, access and/or accuracy of interactions between devices by implementing a specific new method and system as defined herein. The present invention is a specific advancement in the area of peer to peer transfer and provides benefits in security, privacy, and the ability to easily validate participants in the peer to peer transfer even in situations where the participants are unable to communicate with a network or other authority.

As used herein, the term "digital wallet" refers to an application installed on a user device that allows a user to participate in coin transactions with other digital wallets configured pursuant to the present invention. Each digital wallet may store some indication of an amount (or balance) of "value" contained within the digital wallet. The value may be, for example, an amount of coins as well as other value (such as a currency value) or the like.

<FIG> is a high-level block diagram of a system <NUM> according to some embodiments of the present invention. As shown, the system <NUM> includes several entities that may be involved in offline coin transactions of different types pursuant to embodiments of the present invention. For example, the system <NUM> may include one or more users operating user devices <NUM>, <NUM>, one or more coin service providers <NUM> and one or more funding service providers <NUM>. Depending on the nature of a transaction, one or more of the entities may interact with other entities via a network <NUM>. However, in some embodiments, interactions between user devices <NUM>, <NUM> may typically include offline interactions (e.g., where one user device interacts with another via a local connection such as Bluetooth, Bluetooth LE, near field communications (NFC), infrared (IR), WiFi, or the like). One or more of the user devices <NUM>, <NUM> may be, for example, mobile devices such as smart phones or the like. User devices <NUM>, <NUM> may also be smart watches, fitness trackers, or other devices that may operate to store and transfer coins securely as described herein.

As will be described further herein, only certain transactions involve the coin service provider <NUM> and the funding service provider <NUM> (transactions such as the registration process of <FIG>, the coin purchase process of <FIG>, the coin verification process of <FIG> or the verification process of <FIG>), while transactions involving the transfer of coins between users typically only involve the user devices <NUM>, <NUM>. That is, pursuant to some embodiments, users operating user devices <NUM>, <NUM> may exchange value in offline environments, without involvement of online devices (such as coin service providers <NUM> or the like). In this manner, embodiments allow users to securely and reliably exchange value even in situations where no Internet or other connectivity is available.

As shown in <FIG> (and as will be described in further detail below), a coin service provider <NUM> maintains a repository or database(s) containing all coins created and in circulation (shown as coin data store <NUM>). The coin data store <NUM> contains detailed information about the status of each coin (where each coin is associated with a coin serial number "SerialN"). The status information associated with each coin may include, for example, the number of each coin (which may be, for example, a numeric that simply increments each time the coin service provider <NUM> issues a new coin), a coin serial number "SerialN", a digital representation of the coin ("DigitalCoin"), information identifying the user that currently owns the coin ("UserID") as well as information identifying the user that previously owned the coin ("Prev UserID").

The user information (including UserID and Prev UserID) may, for example, be or include a pointer or reference to data in a user data store <NUM> which stores information identifying users participating in the system of the present invention. In some embodiments, the user data store <NUM> stores information about users who have registered to participate in the system of the present invention (e.g., to acquire, transfer, and redeem coins). A registration process pursuant to some embodiments will be discussed below in conjunction with <FIG>. In general, information stored or associated with the user data store <NUM> includes information identifying each user as well as a public key associated with the user ("UserPublicKey") and a code or personal identification number selected by the user during registration ("UserPIN"). The UserPublicKey is used to encrypt a coin payload for transmission and the UserPIN is used to verify the coin was transferred to the recipient. Further details of transactions using the data from the coin data store <NUM> and the user data store <NUM> will be provided below.

In some embodiments, to purchase a coin issued pursuant to the present invention, a user may be required to purchase the coin using a fiat currency (such as U. Dollars or the like). In order to make such a purchase, one or more funding service providers <NUM> may be used to facilitate the purchase transaction. Similarly, in some embodiments, to convert a coin into a fiat currency (such as U. Dollars or the like), one or more funding service providers <NUM> may be used to facilitate the transaction.

Prior to conducting a transaction, each of the users may enroll their respective user devices <NUM>, <NUM> to participate in the coin system of the present invention by downloading a wallet application <NUM>, <NUM> onto their user device <NUM>, <NUM> and performing a registration process (such as the one described below in conjunction with <FIG>). Each wallet application <NUM>, <NUM> may be configured with one or more cryptographic algorithms and related data in order to conduct transactions pursuant to the present invention as will be described further herein. In some embodiments, each wallet application <NUM>, <NUM> is also configured with a public key cryptography system that allows each participating wallet application <NUM>, <NUM> to exchange information with other participants in the system <NUM> using a standard public/private key encryption mechanism.

Pursuant to some embodiments, the coin service provider <NUM> may be a payment network service provider such as, for example, Mastercard International Incorporated (referred to herein as "Mastercard"). The funding service provider <NUM> may be a financial institution that is able to interact with wallet applications <NUM>, <NUM> of the present invention (e.g., by confirming the validity of coins in a wallet as described herein) and is able to conduct value transfers with those wallet applications (or with other accounts of the users). Interactions with a funding service provider <NUM> may result in value being exchanged into (or from) a fiat currency or other tangible forms of value. For example, a coin (or group of coins) having a value of $<NUM> of value that are stored in wallet <NUM> of user device <NUM> may be converted into $<NUM> by interacting with a funding service provider <NUM>. Funds may be transferred to (or from) credit cards, bank accounts, or other sources of value such as PayPal or the like. In some embodiments, the coin service provider <NUM> and the funding service provider <NUM> may be or may be operated by or on behalf of the same entity.

In some embodiments, the coin service provider <NUM> serves as a central institution to create and convert coins in the system <NUM>. In some embodiments, a public/private key infrastructure is used as a framework for issuing, transmitting and validating coins. For example, in some embodiments, the coin service provider <NUM> has two sets of public and private keys - one pair referred to as "SendCoin" (and including "SendCoinPublic" and "SendCoinPrivate") and the other pair referred to as "ReceiveCoin" (and including "ReceiveCoinPublic" and "ReceiveCoinPrivate"). The SendCoin key pair is used to encrypt coins when a user acquires the coins from the coin service provider <NUM>. The SendCoinPublic key is used by the coin service provider <NUM> to encrypt a coin payload and the SendCoinPrivate key is then used by a wallet application <NUM>, <NUM> to decrypt the coin payload when received by a user device <NUM>, <NUM>.

The ReceiveCoin key pair is used to encrypt coins for transmission back to the coin service provider <NUM>. For example, the ReceiveCoinPublic key (which is stored in each wallet application <NUM>, <NUM>) is used to encrypt a coin payload for transmission from a user device <NUM>, <NUM> to the coin service provider <NUM> (e.g., when the user wishes to redeem coin(s) for a fiat currency). The coin service provider <NUM> uses the ReceiveCoinPrivate key to decrypt the coin payload. Further details of this public key infrastructure and how it is used in different transactions and scenarios will be described further below.

Pursuant to some embodiments, the user devices <NUM>, <NUM> may be portable devices that can be transported and be operated by a user, and may include one or more electronic components (e.g., an integrated chip, etc.). A user device according to some embodiments may be in any suitable form including, but not limited to a mobile phone (e.g., smart phone, cellular phone, etc.), a tablet computer, a portable media player, a personal digital assistant device (PDA), a wearable communication device (e.g., watch, bracelet, glasses, etc.), an electronic reader device, a laptop, a netbook, an ultrabook, etc. A user device may also be in embodied in other form factors (such as, for example, a component in a vehicle equipped with communication capabilities).

Some or all of the processing described herein may be performed automatically or otherwise be automated by one or more computing devices or systems. As used herein, the term "automate" may refer to, for example, actions that can be performed with little (or no) intervention by a human. While only two user devices <NUM>, <NUM> are shown in <FIG>, in practical application, a large number of user devices would interact with each other and with one or more coin service providers <NUM> and funding service providers <NUM>.

Further details of some embodiments will now be described by reference to <FIG> where a registration process <NUM> is shown from the perspective of a user device such as user device <NUM>). Registration process <NUM> begins at <NUM> where a user interacts with a user device <NUM> to install a wallet application <NUM> pursuant to the present invention. For example, the user may direct a browser of the user device <NUM> to an application download page hosted by or on behalf of a coin service provider <NUM>. The application will be generally referred to herein as a wallet application (such as the wallet application <NUM> of user device <NUM>) and may provide functionality to allow a user to purchase, store and transfer coins pursuant to the present invention. While the application may contain a wallet to store coins to be used to purchase or transfer to other users, it may contain additional functionality as well.

When the application has been downloaded or otherwise installed on the user device <NUM>, processing continues at <NUM> where the user is prompted to create a public/private key pair which will be used to encrypt or decrypt any payload associated with the transfer of coins into or out of the wallet application <NUM>. Creation of the public/private key pair may be performed by simply prompting the user to select a menu option or button to generate the keys (which may cause the application to use information about the user device and time to generate the keys and store them in the wallet application). Processing at <NUM> may also include communicating the details of the UserID as well as the generated UserPublicKey to the coin service provider <NUM> for storage in the user data store <NUM>.

Processing continues at <NUM> where the user is prompted to select a UserPIN that will be associated with the user's UserID to verify any transfer of coins from the user to other users. Processing at <NUM> may also include communicating the UserPIN to the coin service provider <NUM> for storage in the user data store <NUM>. In some embodiments, the UserPIN may be generated on behalf of the user. At the end of the registration process <NUM>, the user has a user device <NUM> configured with a wallet application <NUM> that can purchase, store and transfer coins pursuant to the present invention.

Once a user device <NUM>, <NUM> has been configured with a wallet application <NUM>, <NUM> and the user has performed a registration process (such as the one described in <FIG>), the user may use the user device <NUM>, <NUM> to conduct transactions pursuant to the present invention. A user may choose to conduct a coin purchase transaction process such as the process <NUM> shown in <FIG> in order to acquire one or more coins that may then be used to conduct coin purchase transactions. Process <NUM> begins at <NUM> where a user (such as a user of device <NUM>) interacts with a coin service provider <NUM> to initiate a coin purchase from the coin service provider <NUM>. For simplicity and ease of exposition, the process <NUM> will be described using an example where a user purchases a single coin - those skilled in the art, upon reading the present disclosure, will recognize that the process may be extended to purchases involving multiple coins.

The interaction at <NUM> may include the user device <NUM> and the wallet application <NUM> being operated to initiate a request to purchase a coin as well as to provide funding information. In some embodiments, the funding information may be payment card or payment account information. The request may be performed in a typical shopping cart type of a transaction (e.g., where the user interacts with a shopping cart to select a quantity of coin(s) as well as to provide payment information). In some embodiments, the funding transaction may be performed using or in conjunction with a funding service provider <NUM>. Processing continues at <NUM> where the funding information is verified and, if verified, processing continues at <NUM> where the coin service provider <NUM> performs processing to issue the coin that have been purchased.

Processing continues at <NUM> where the coin service provider <NUM> creates a hash of DigitalCoin (the digital representation of the purchased coin) and UserID (the UserID of the user purchasing the coin) using the SerialN (the serial number of the purchased coin) using a hashing algorithm that is supported and used by all devices on in the system <NUM> (e.g., SHA-<NUM> or the like). The resulting hash is referenced as Hash[DigitalCoin, UserID, SerialN] or HASH. Processing continues at <NUM> where the coin information ("Colnfo") is encrypted using the coin service provider <NUM> public key (that is, SendCoinPublic[CoInfo] is generated). The Colnfo (or the coin payload) is the HASH +UserID+DigitalCoin+SerialN. At this point, the coin payload ("CoInfo") has been encrypted by the SendCoin public key and can only be decrypted by the SendCoin private key which has been distributed to wallet applications <NUM>, <NUM>. The purpose of this encryption is to allow any user having wallet applications <NUM>, <NUM> to use the application to verify the validity of the coin (as described below in conjunction with <FIG>).

Processing continues at <NUM> where the coin service provider <NUM> encrypts the encrypted coin payload SendCoinPublic[CoInfo] with the public key of the user who purchased the coin. The resulting payload can be represented as ReceiveCoinPublic[SendCoinPublic[Colnfo]]. At this point, only the user who purchased the coin can decrypt and utilize the coin using the user's ReceiveCoinPrivate key. Processing continues at <NUM> where the encrypted payload ReceiveCoinPublic[SendCoinPublic[CoInfo]] is transmitted to the user's wallet application <NUM>. At the end of process <NUM>, a user (such as the user operating user device <NUM> of <FIG>) may have information as shown in <FIG> in the user's wallet application <NUM> (including a coin having a serial number, encrypted coin information, and hash of the payload). The user may now interact with other users in the system to transfer the coin in offline coin transactions pursuant to the present invention.

Prior to a discussion of how offline coin transactions between users are conducted, reference will first be made to <FIG> where a process <NUM> for verifying the validity of a coin will be described. The process <NUM> may be performed at any time that a user or participate in the system <NUM> wishes to verify the validity of a coin. For example, the user of user device <NUM> may wish to verify the validity of coin serial number <NUM> (which is shown as a coin in the user's wallet application <NUM> in <FIG>). The verification process <NUM> begins at <NUM> where the user initiates a coin verification process by, for example, selecting a coin verification option available in the wallet application <NUM>. Processing continues at <NUM> where the wallet application functions to decrypt the encrypted coin (by decrypting SendCoinPublic[Colnfo] from the received payload ReceiveCoinPublic[SendCoinPublic[CoInfo] by using user's ReceiveCoinPrivate key) to obtain SendCoinPublic[Colnfo]. Processing at <NUM> may further include processing where the wallet application functions to decrypt the encrypted coin (by decrypting SendCoinPublic[CoInfo] using SendCoin private key which is available in the wallet application to obtain the clear text Hash[DigitalCoin, UserID, SerialN], DigitalCoin, UserID, and SerialN (where Hash[DigitalCoin, UserID, SerialN] is referred to herein as the stored hash). Processing continues at <NUM> where a hash is created (the "created hash") using DigitalCoin, UserID and SerialN (using the serial number and using a hashing algorithm that is supported and used by all devices in the system <NUM> such as, for example SHA-<NUM> or the like). At <NUM> a determination is made whether the created hash is equal to the stored hash. If so, the coin has been verified and processing continues at <NUM> and the user is informed of the success - that the coin was verified. If not, the coin has not been verified and processing continues at <NUM> and the user is informed of the failure - that the coin was not verified. In such a situation, the user may be able to decline a transaction or otherwise refused to accept the coin as described elsewhere herein.

Reference is now made to <FIG>, where an offline coin transaction process <NUM> pursuant to some embodiments is shown. The process <NUM> is from the perspective of the buyer (the user operating a user device <NUM> in <FIG>). The seller side of the process will be described in conjunction with <FIG>.

In general, before an offline coin transaction can occur between two users, both users must have registered to participate in the system of the present invention (e.g., each user must have performed a registration process such as that shown in <FIG> and each user must have a wallet application <NUM>, <NUM>). Further, each user must have a public/private key pair. Transaction process <NUM> begins at <NUM> where a buyer (such as the user operating user device <NUM> of <FIG>) transmits a purchase request to a seller (such as the user operating user device <NUM> of <FIG>) over a secure communication channel. As discussed above, the communication between user devices need not be "online" (e.g., it may not need the Internet). Instead, the communication between the devices may be over a local communication channel such as NFC, Bluetooth, or the like.

Once the connection has been established, the seller user device <NUM> transmits a hash of the wallet application <NUM> executable code and the seller's public key to the buyer user device <NUM>. In some embodiments, the hash of the executable code uses the current date as the key input to the hashing algorithm. Since the wallet application <NUM> of the seller user device <NUM> is the same as the wallet application <NUM> of the buyer user device <NUM>, the buyer should be able to generate a hash of wallet application <NUM> executable code (again using the current date as they key input to the hashing algorithm) and get the same hash value as the hash value provided by the seller. If the hash values don't match, processing continues at <NUM> and the transaction is canceled.

If the hash values do match, processing continues at <NUM> where the buyer (the user operating user device <NUM> of <FIG>) decrypts a coin from the wallet application <NUM> using the buyer user's privatekey. At this point, the coin payload only has the encryption performed by the coin service provider <NUM> (or, SendCoinPublic[CoInfo]) and the payload can be prepared for transmission to the seller.

Processing continues at <NUM> where the buyer user operates the wallet application <NUM> of the user device <NUM> to generate a hash (Hash4Pass[SendCoinPublic[Colnfo]]) by adding a hash to the payload from <NUM> using a passcode (such as a four-digit passcode in this example). The payload is now the buyer's UserID, the seller's UserID, the location, the time, SendCoinPublic[Colnfo] and Hash4Pass[SendCoinPublic[Colnfo]].

Processing continues at <NUM> where the buyer user operates the wallet application <NUM> of the user device <NUM> to generate another hash using the buyer's PIN (BuyerPIN) which is stored in the coin service provider <NUM> user data store <NUM>. The payload is now the buyer's UserID, the seller's UserID, the location, the time, SendCoinPublic[CoInfo], Hash4Pass[SendCoinPublic[CoInfo]] and BuyerPINHash[Hash4Pass[SendCoinPublic][CoInfo]].

Processing continues at <NUM> where the payload is encrypted with the seller public key (which was received at <NUM>). This effectively transfers ownership of the coin to the seller (the user operating user device <NUM> in the illustrative example presented herein that refers to <FIG>). At this point, the buyer (the previous owner of the coin and the operator of user device <NUM>) can't use the coin anymore or transfer it to a different person as the coin has been encrypted using the seller public key. The seller is the only user that has access to decrypt the payload and all the information it contains. The encrypted information may be represented as SellerPublicKey[CoinTransferInfo]. This information is provided to the seller via the secure communication channel established between devices <NUM> and <NUM>.

At this point, the seller uses the seller private key to decrypt the payload in SellerPublicKey[CoinTransferInfo] to produce the following data: Buyer UserID, Seller UserID, location, time, SendCoinPublic[Colnfo],
Hash4Pass[SendCoinPublic[Colnfo]] and BuyerPINHash[Hash4Pass[SendCoinPublic[CoInfo]]]. The seller now has to verify the coin is valid (e.g., using the process <NUM> of <FIG>). If the coin is not authenticated, the process terminates, and the seller does not complete the transaction. If the coin is authenticated, the seller needs to get the buyer's passcode (e.g., such as the <NUM> digit passcode used in step <NUM>).

Processing continues at <NUM> where the buyer (the user operating user device <NUM>) communicates the buyer's passcode to the seller (the user operating device <NUM>) via different channel (e.g., such as via an SMS message, an email or by voice). The purpose of the passcode is to provide finality of the transaction to both parties. Once the buyer provides the passcode to the seller, the seller can verify the hash Hash4Pass[SendCoinPublic[CoInfo]]. If the verification is successful, the seller can now provide the goods or services to the buyer. Otherwise, if the verification is not successful, although the seller has possession of the coin, it is worthless since the coin service provider <NUM> will not recognize the transfer of ownership (as described further below in conjunction with <FIG>) and the wallet application <NUM> cancels the transaction. If, however, the seller is able to verify the coin, the seller creates a hash of SendCoinPublic[CoInfo] with the seller's private PIN (which is stored in the coin service provider <NUM> user data store <NUM>). The hash is transmitted back to the buyer where it is received at <NUM>. The buyer stores the hash in the wallet application <NUM> in the wallet data store <NUM> for later use in verifying that the coin was actually received by the seller. Once the coin is validated, the coin will remain in the seller's wallet application <NUM> until he is ready to redeem it with the coin service provider <NUM> or otherwise convey it. In some embodiments, the seller has up to <NUM> days to go online and connect the wallet application <NUM> with the coin service provider <NUM> to notify the service provider of the seller's ownership of the coin. Otherwise, the seller risks the possibility of the buyer contesting the ownership of the coin.

Reference is now made to <FIG> where a transaction process <NUM> is shown. The transaction process <NUM> is from the perspective of the seller in the illustrative transaction discussed above (e.g., where the seller is a user operating user device <NUM>). The process <NUM> begins at <NUM> where the wallet application <NUM> of the seller's user device <NUM> receives a purchase request from a buyer over a secure communication channel (e.g., as discussed in conjunction with <NUM> of <FIG>). The seller wallet application <NUM> may respond by providing a hash of the wallet application executable code and the seller's public key. Processing continues at <NUM> where the wallet application <NUM> receives a hash of the application executable code and the buyer's public key from the buyer wallet application <NUM>. Processing at <NUM> may be performed as at <NUM> to confirm the hash. If the hash is not confirmed the seller wallet application <NUM> may cancel the transaction at <NUM>.

If the hash is confirmed, processing continues at <NUM> where the seller wallet application <NUM> receives the payload with SellerPublicKey[CoinTransferInfo] from the buyer wallet application <NUM>. At <NUM>, the seller wallet application <NUM> acts to decrypt the payload using the seller private key to obtain Buyer UserID, Seller UserID, location, time, SendCoinPublic[CoInfo],
Hash4Pass[SendCoinPublic[CoInfo]], and BuyerPINHash[Hash4Pass[SendCoinPublic[CoInfo]]. Processing continues at <NUM> where the seller wallet application <NUM> operates to verify the coin validity (using the process <NUM> of <FIG>). If the process is unable to verify the validity of the coin, processing continues at <NUM> where the wallet application <NUM> cancels the transaction.

If the process is able to verify the validity of the coin, processing continues at <NUM> where the seller obtains the passcode from the buyer (as described in <NUM> above). The passcode is used by the wallet application <NUM> to verify Hash4Pass (as described above). If the hash is not able to be verified, the wallet application <NUM> cancels the transaction. If the hash is verified, processing continues at <NUM> where the wallet application <NUM> generates a hash of SendCoinPublic[Colnfo] with the seller private PIN (which is stored in the coin service provider <NUM> user data store <NUM>) and communicates the hash back to the buyer device <NUM>. As discussed above, the coin now remains in the seller's wallet application <NUM>, and the seller has up to (for example) <NUM> days to notify the coin service provider <NUM> of the seller's ownership of the coin.

The processing of <FIG> may be performed in an offline environment (e.g., where there is no Internet or cellular data connectivity). In some embodiments, the user devices <NUM>, <NUM> are required to confirm the status of coins by going in an online mode from time to time (for example, at least once every <NUM> days, etc.). A process for verifying ownership <NUM> will now be described by reference to <FIG>. The process <NUM> is generally described from the perspective of a coin service provider <NUM> when the coin service provider <NUM> is in communication with a wallet application <NUM>, <NUM>. Pursuant to some embodiments, wallet applications <NUM>, <NUM> are configured to automatically initiate the performance of a verification process <NUM> when the wallet applications <NUM>, <NUM> detect that the user device <NUM>, <NUM> is in communication with the Internet or is otherwise able to communicate with coin service provider <NUM>. For simplicity, the process <NUM> will be described by reference to the wallet application <NUM> associated with the user device <NUM>.

Processing begins at <NUM> where the coin service provider <NUM> identifies that it is in an online session with a wallet application <NUM>. Those skilled in the art will appreciate that the coin service provider <NUM> may undertake a large number of such interactions in parallel (e.g., to verify ownership of coins in a large number of wallet applications substantially at the same time). Processing at <NUM> may include receiving information about the user (including, for example, a UserID) as well as information about the wallet application. Processing continues at <NUM> where the coin service provider <NUM> identifies the next coin to verify in the wallet application <NUM>. Information associated with the next coin is received from the wallet application <NUM>, and the process determines whether the coin had its ownership transferred out of the wallet application <NUM> (for example, since the last time that the coins in the wallet application <NUM> were verified, was the coin sold or otherwise conveyed to another user?). If so, processing continues at <NUM> where a determination is made whether the ownership of that specific coin was previously updated. For example, if the coin was transferred to a seller operating wallet application <NUM> and that seller performed the process <NUM> before the buyer did, then processing at <NUM> will determine that the ownership of the coin was previously updated, and the transferred coin will be permanently removed from the wallet application <NUM> at <NUM>.

If, however, the ownership of the coin that was transferred out has not yet been updated, processing continues at <NUM> where the user of the user device <NUM> associated with the wallet application <NUM> will be prompted to confirm whether the transaction involving the coin had completed successfully. If the user confirms the transaction, processing continues at <NUM> where the coin service provider <NUM> performs processing to confirm the hash of SendCoinPublic[CoinInfo]. The hash is confirmed by the coin service provider <NUM> using the recipient's private PIN (which is stored in the coin service provider <NUM> user data store <NUM>) to generate a hash of SendCoinPublic[CoinInfo] and to compare it to the hash provided by the recipient of the coin (e.g., the hash received at <NUM> of <FIG>). A match confirms that the coin was received by the recipient and the coin ownership has been updated. In this manner, the coin service provider <NUM> can reliably confirm the ownership transfer of a coin even in the event where the recipient of that coin has been unable to perform any online processing. If, however, the user does not confirm the transaction at <NUM>, processing continues at <NUM> where the coin status is updated as "disputed". In that situation, if the alleged recipient of the coin does not connect to the coin service provider <NUM> within a period of time (such as, for example, <NUM> days from the date of the alleged transaction), the ownership will be set to remain with the original user in the transaction.

If processing at <NUM> for a specific coin indicates that the coin is not one that was transferred out of the wallet application <NUM> (but instead is a coin that was transferred into the wallet application <NUM>), processing continues at <NUM> where the coin is verified. For example, the coin may be verified by the coin service provider <NUM> performing the verification processing of <FIG>. Further, the coin service provider <NUM> may use the passcode (provided from the buyer to the seller as described above in steps <NUM> and <NUM> of <FIG> and <FIG> respectively) to verify the hash. Finally, the coin service provider <NUM> may verify that the entire payload was actually sent by a user by using the user's PIN to create it to the hash sent at step <NUM> of the process of <FIG>. If these verifications succeed, processing continues at <NUM> where the coin ownership is updated. That is, the coin data store <NUM> record for that specific coin is updated to reflect the current owner's UserID and the previous owner's UserID. The new owner can then use the coin as set forth herein (e.g., to convey it to another user or to redeem the coin for a fiat currency).

The embodiments described herein may be implemented using any number of different hardware configurations. <FIG> illustrates a mobile device <NUM> that may be used in any of the methods and processes described herein, in accordance with an example embodiment. For example, the mobile device <NUM> may be operated as either the user device <NUM> or the user device <NUM> of <FIG>.

In some embodiments, device <NUM> can include some or all of the components described with respect to <FIG>. The device <NUM> may be a user device such as the user devices <NUM> and <NUM> of <FIG>. Device <NUM> has a bus <NUM> or other electrical components that operatively couple an input/output ("I/O") section <NUM> with one or more computer processors <NUM> and memory section <NUM>. I/O section <NUM> can be connected to a display <NUM>, which can have one or more aspects such as a touch-sensitive component (not shown). In addition, I/O section <NUM> can be connected with communication unit <NUM> for receiving application and operating system data, using Wi-Fi, Bluetooth, near field communication (NFC), cellular, and/or other wireless communication techniques (e.g., to allow the device <NUM> to interact with other user devices to conduct transactions as described herein or to interact with funding service providers <NUM> and coin service providers <NUM>). Mobile device <NUM> can include one or more input mechanisms <NUM> such as a keypad, a button, a touch-screen display, or the like.

Input mechanism <NUM> is, optionally, a microphone, in some examples. Mobile device <NUM> optionally includes various sensors (not shown), such as a GPS sensor, accelerometer, directional sensor (e.g., compass), gyroscope, motion sensor, and/or a combination thereof, all of which can be operatively connected to I/O section <NUM>.

Memory section <NUM> mobile device <NUM> can include one or more non-transitory computer-readable storage mediums, for storing computer-executable instructions, which, when executed by one or more computer processors <NUM>, for example, can cause the computer processors to perform the techniques described below, including processes <NUM> -<NUM>. A computer-readable storage medium can be any medium that can tangibly contain or store computer-executable instructions for use by or in connection with the instruction execution system, apparatus, or device. In some examples, the storage medium is a transitory computer-readable storage medium. In some examples, the storage medium is a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium can include, but is not limited to, magnetic, optical, and/or semiconductor storages. Examples of such storage include magnetic disks, optical discs based on CD, DVD, or Blu-ray technologies, as well as persistent solid-state memory such as flash, solid-state drives, and the like. Mobile device <NUM> is not limited to the components and configuration of <FIG> but can include other or additional components in multiple configurations.

Memory section <NUM> may store one or more applications 822a-n including, for example, a wallet application <NUM>, <NUM> as described herein as well as data (including the wallet data stores <NUM>, <NUM>) and related key information.

As will be appreciated based on the foregoing specification, the above-described examples of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof. Any such resulting program, having computer-readable code, may be embodied, or provided within one or more non-transitory computer-readable media, thereby making a computer program product, i.e., an article of manufacture, according to the discussed examples of the disclosure. For example, the non-transitory computer-readable media may be, but is not limited to, a fixed drive, diskette, optical disk, magnetic tape, flash memory, external drive, semiconductor memory such as read-only memory (ROM), random-access memory (RAM), and/or any other non-transitory transmitting and/or receiving medium such as the Internet, cloud storage, the Internet of Things (IoT), or other communication network or link. The article of manufacture containing the computer code may be made and/or used by executing the code directly from one medium, by copying the code from one medium to another medium, or by transmitting the code over a network.

The computer programs (also referred to as programs, software, software applications, "apps", or code) may include machine instructions for a programmable processor and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, cloud storage, internet of things, and/or device (e.g., magnetic discs, optical disks, memory, programmable logic devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The "machine-readable medium" and "computer-readable medium," however, do not include transitory signals. The term "machine-readable signal" refers to any signal that may be used to provide machine instructions and/or any other kind of data to a programmable processor.

Claim 1:
A computerized method (<NUM>) for operating a first device (<NUM>) to receive a coin having value from a second device (<NUM>) while the first device (<NUM>) and the second device (<NUM>) are offline or otherwise unable to communicate with a central issuing authority or payment network, the method comprising:
receiving, by the first device (<NUM>), over a local communication channel, information to confirm the validity of the second device (<NUM>), wherein the information to confirm the validity of the second device (<NUM>) includes a hash of application executable code of a wallet application (<NUM>) of the second device (<NUM>), and wherein the validity is confirmed if the first device (<NUM>) can validate the hash of application executable code by generating the same hash using application executable code of a wallet application of the first device (<NUM>);
receiving, by the first device (<NUM>), over the local communication channel, a coin transfer message from the second device (<NUM>), the coin transfer message including coin information, wherein the coin information includes a hash generated using a passcode;
receiving, by the first device (<NUM>), over a channel other than the local communication channel, the passcode from a user of the second device (<NUM>);
verifying, by the first device (<NUM>), information in the coin transfer message by using the passcode to verify the hash included in the coin information; and
generating, by the first device (<NUM>), a hash of the coin information using a PIN associated with the first device (<NUM>).