SYSTEM AND METHOD FOR TOKEN MANAGEMENT

Abstract

Systems and methods for use in token management are provided. One example computer-implemented method includes receiving a request from a first user to redeem a first token having a first value, the first token being issued by a consortium of multiple parties. In response to the request, the method includes identifying one of the multiple parties to settle the redemption for the first token based on one or more criteria. The method then includes initiating a transfer of the first value from one of the multiple parties to an account specific to the first user.

Description

[Technical Field]

[0001] The present disclosure generally relates to systems and methods used to manage token exchanges between participants.

[0002] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 423,742, filed November 8, 2022, the entire disclosure of which is incorporated herein by reference. [Background technology]

[0003] This section provides background information related to the present disclosure that is not necessarily prior art.

[0004] Parties are known to rely on different types of ledgers to manage their interactions. For example, blockchain ledgers are known to be used to manage the exchange of cryptocurrencies between parties. Entries in a blockchain ledger are immutable and provide evidence of the chain of ownership of the cryptocurrency. Summary of the Invention

[0005]

[0013] Exemplary embodiments are more fully disclosed with reference to the accompanying drawings, in which:

[0014] The disclosure and specific examples contained in this disclosure are intended for purposes of illustration only and are not intended to limit the scope of the disclosure.

[0006] Users can exchange monetary value in a variety of forms. Users can choose a monetary form specific to their transaction based on security and accessibility, such as cash, debt, or cryptocurrency. For example, fiat currencies can be exchanged as bearer money or converted into tokens. However, traditionally, the exchange of tokens is associated with considerations such as security, acceptability, accessibility, and / or convenience.

[0007] A unique aspect of the disclosed systems and methods is the provision of exchange of fiat-backed tokens, either via single-token or multi-token schemes. In particular, a particular token may be minted, e.g., via an immutable ledger, backed by fiat currency, secured by either a party (or parties) or the token's host, and the token may be acceptable for exchange as a form of monetary transfer between users associated with the parties (e.g., transferring 10 USDM-A in exchange for transferring $10 USD). Tokens may be exchanged directly or in exchange for other tokens, thereby expanding the token's acceptability, accessibility, and / or usefulness. [Brief explanation of the drawings]

[0008] The drawings of the present disclosure are only for purposes of illustrating selected embodiments (not all possible embodiments) and are not intended to limit the scope of the present disclosure.

[0009] [Figure 1] FIG. 1 illustrates an example system of the present disclosure suitable for use in token management. [Figure 2] FIG. 2 is a block diagram illustrating an example of a computing device that can be used in the system of FIG. 1. [Figure 3] 2 is a flow diagram illustrating an exemplary method for token management that may be implemented in connection with the system of FIG. 1. [Figure 4] 4 includes additional example flows for use in token management that may be implemented in conjunction with the system of FIG. 1 and / or the method of FIG. 3. [Figure 5] 4 includes additional example flows for use in token management that may be implemented in conjunction with the system of FIG. 1 and / or the method of FIG. 3.

[0010] Corresponding reference characters indicate corresponding parts throughout the various views. DETAILED DESCRIPTION OF THE INVENTION

[0011] 1 illustrates an exemplary system 100 in which one or more aspects of the present disclosure may be implemented. Although system 100 is shown in one arrangement, other embodiments may include portions of system 100 (or other portions) arranged in other ways, depending on the type of token, the parties, privacy regulations and / or requirements, etc.

[0012] The system generally includes parties 102, 104, 106, a token host 108, and a ledger 110, each coupled to (and in communication with) a network 112. Network 112 may include, but is not limited to, one or more local area networks (LANs), wide area networks (WANs) (e.g., the Internet), mobile networks, virtual networks, and / or other suitable public and / or private networks capable of supporting communication between two or more of the portions depicted in FIG. 1, as well as combinations thereof.

[0013] Each of the parties 102, 104, and 106 is typically a financial institution, such as a bank. More generally, the parties 102, 104, and 106 are configured to issue accounts to each of the users 114, 116, and 118, which may include financial institution accounts (e.g., checking accounts, savings accounts, credit accounts, etc.), in which fiat currency is held by each party on behalf of the corresponding user (the person to whom the party issues the account). The user may then cooperate with each party to transfer the fiat currency to another user(s) or another party(ies) for one or more purposes. Note that while the accounts issued by the parties 102, 104, and 106 in this example include fiat currency or government-issued currency, the accounts may also include other forms of currency.

[0014] In this exemplary embodiment, party 102 is also referred to as Bank A (or Party A) and is configured to issue an account to user 114 (i.e., Alice); party 104 is also referred to as Bank B (or Party B) and is configured to issue an account to user 116 (i.e., Bob); and party 106 is also referred to as Bank C (or Party C) and is configured to issue an account to user 118 (i.e., Carrie). Each account is associated with and / or includes an amount of fiat currency (e.g., $100 USD, etc.). As further shown in FIG. 1, Alice, Bob, and Carrie are each associated with a communication device 120, 122, and 124, respectively. Each communication device may include a portable device, such as a smartphone, tablet, etc., that is configured to communicate with the other devices / components of FIG. 1 via network 112. In this exemplary embodiment, each communication device 120, 122, 124 includes a wallet application or other suitable program or web browser that configures the communication device to function as described above. In particular, by way of example, communication devices 120, 122, 124 are each configured to communicate with ledger 110 to determine balances for one or more different types of tokens associated with or held by respective users, such as Alice, Bob, and Carrie. For example, communication device 120, via its included wallet application, is configured to retrieve from ledger 110 balances for USDM-A, USDM-B, and / or USDM-C that are reflected in each smart contract on ledger 110 as being held by Alice, etc.

[0015] In system 100, each of parties 102, 104, and 106 and the token host 108 are configured to mint tokens in relation to ledger 110. That is, for example, party 102 is configured to request that a number of tokens be minted for a specific user, and ledger 110 is configured to generate tokens specific to party 102 (e.g., specific to party 102's smart contract), assign the tokens to the specific user, and confirm this to party 102. Each token is generally a piece or string of data, generated based on one or more methods (e.g., via keys, secrets, etc.). Tokens are generally unique and may conform to one or more forms, standards, or formats, and may or may not include an indication of the party that minted / generated the token. For example, tokens may be fungible, such that a USDM-A token is generally indistinguishable from another USDM-A token once minted or issued. Ledger 110 is configured to generate and record tokens (e.g., as part of a smart contract, etc.) in a data structure, such as a blockchain or other immutable data structure, along with data about the parties minting the tokens and the holders of the tokens.

[0016] Given the above, there are several different embodiments for tokens in system 100, which are described in this disclosure, in which a token or multiple tokens can be exchanged in lieu of fiat currency.

[0017] In a first exemplary embodiment, each party 102, 104, 106 is configured to mint a token specific to that party. Each party is configured to create a smart contract and record the smart contract in the ledger 110, and the party is allowed to mint a token specific to its smart contract. That is, by way of example, Bank A (e.g., party 102) is configured to mint USDM-A tokens, Bank B (e.g., party 104) is configured to mint USDM-B tokens, and Bank C (e.g., party 106) is configured to mint USDM-C tokens.

[0018] In this particular example, Bank A includes an account specific to Alice, which contains $100 USD. If Alice requests to convert $20 USD into $20 USDM-A tokens, Bank A is configured to mint $20 worth of USDM-A (e.g., pursuant to a smart contract in ledger 110, etc.), create an entry in ledger 110 for the USDM-A indicating the transfer, and read from ledger 110 to reflect the 20 USDM-A in a wallet application in communication device 120 (associated with Alice). The entry in ledger 110 includes the USDM-A token, the amount, and the holder (i.e., Alice). Note that in this example, the token (i.e., USDM-A) is specific to Bank A and includes an identifier for Bank A. Bank A is also configured to debit Alice's account for $20 USD. Consequently, Alice's account at Bank A now has $80 USD and 20 USDM-A, and the $20 is transferred to Bank A's account underlying the minting of the USDM-A token. Note that USDM-A may be one or more tokens equivalent to different currency denominations. In this exemplary embodiment, each USDM-A token may be worth $1 USD. Note that other tokens in other embodiments may comprise different currency denominations.

[0019] For example, Alice may then be allowed to transfer 5 USDM-A to Bob, whereby the wallet application configures the communication device 120 to initiate a transfer transaction (e.g., in the amount of $5 USD), resulting in the 5 USDM-A being placed into the wallet application on Bob's communication device 122. An entry is generated by the wallet application (or a host associated with the wallet application, such as the token host 108) and / or ledger 110, indicating the transfer of the token from Alice to Bob.

[0020] Thus, Alice retains 15 USDM-A and Bob receives 5 USDM-A. Note that while Bob has an account with Bank B, the 5 USDM-A is associated with and / or minted by Bank A.

[0021] Accordingly, for Bob to redeem USDM-A, Bank B is configured to initiate a transfer with Bank A over a payment processing network (e.g., the MASTERCARD network, etc.) (e.g., via traditional ISO 8583 messaging, ISO 20022 messaging, etc.). The payment processing network can be configured to identify Bank A from USDM-A, validate the token / transaction for potential fraud, risk, etc., and send a redemption request including USDM-A to Bank A, which can then be configured to validate the token, transfer, etc. Once validation is achieved (e.g., based on various techniques (e.g., key validation, validation against ledger 110, etc.), etc.), Bank A is configured to approve the redemption, whereby the account number for the USDM-A account is provided, along with one or more other identifiers specific to the redemption, for example. In response, Bank B is configured to create an entry in a clearing file associated with the payment processing network (e.g., between USDM-A account and Bob's account) and post the entry to ledger 110, which will "burn" or erase the exchanged tokens. In this regard, Bank A is configured to include in its clearing file a debit to and exchange for the exchanged value for USDM-A account. Banks A and B are configured to submit their respective clearing files, and as part of the clearing, the processing network is configured to transfer funds from Bank A to Bank B (specifically, to Bob's account at Bank B).

[0022] It should be noted that various different types of token transfers can be completed in a manner consistent with the above. It should also be noted that other parties can mint their own specific tokens, e.g., a USDM-B token specific to Bank B and a USDM-C token specific to Bank C, which will be reflected in each user's wallet application and transferred as described above.

[0023] Additionally, it should be noted that tokens minted by different parties 102, 104, 106 may be associated with and / or recorded in one or more different smart contracts (broadly, data structures that can be programmed) in ledger 110 or in different ledgers (e.g., USDM-A may be recorded in ledger 110, while USDM-B may be recorded in a different ledger, etc.). In such embodiments, the smart contracts under which the tokens are minted may be recorded in different ledgers, and the token may potentially indicate not only the minting bank, but also the specific ledger and smart contract on which the token was minted.

[0024] In a second embodiment, each party 102, 104, 106 is a participant in a consortium or in some other relationship as agreed upon by the participants / parties. In this example, a single smart contract is created (based on terms specific to the consortium or otherwise) and recorded on the ledger 110. Each party 102, 104, 106 is then configured to mint USDM via the same smart contract. That is, the USDM is agnostic with respect to all of the banks / parties in the consortium (and generally indistinguishable to the bank that minted the token).

[0025] In particular, Bank A includes an account specific to Alice, which contains $100 USD. If Alice requests to convert $20 USD into $20 USDM tokens, Bank A is configured to mint the 20 USDM (e.g., pursuant to a smart contract on ledger 110, etc.), create an entry on ledger 110 containing the tokens USDM and the holder (i.e., Alice), and reflect the 20 USDM in a wallet application in communication device 120 associated with Alice based on a read from ledger 110. Further, Bank A is configured to debit $20 USD from Alice's account and credit $20 USD to a joint account associated with USDM at Bank A or another bank. Note again that, as discussed above, in this example, the tokens (i.e., USDM) are not generally specific to Bank A.

[0026] Additionally or alternatively in this example, Bank A may be configured to mint 1000 USDM or some other amount of general USDM, funded by Bank A's funds, and the USDM included in an account specific to Bank A. Then, when Alice requests tokens, Bank A is configured to transfer the appropriate amount of already-minted USDM from its account to Alice (and specifically, Alice's wallet application) and debit Alice's account for the fiat currency associated with the tokens. Bank A is configured to indicate the transfer to Alice via an entry in ledger 110.

[0027] Bank B and Bank C are configured to similarly act via ledger 110 to mint tokens (USDM) for Bob and Carrie.

[0028] Concomitant with the above, users Alice, Bob, and Carrie can transfer tokens to one another. For example, Alice and Bob can each transfer, say, 5 USDM to Carrie, and the 5 USDM is moved into the smart contract on ledger 110, updating each of Alice's, Bob's, and Carrie's balances and reflecting them in the wallet applications on communication devices 120 and 122, as well as Carrie's wallet application on communication device 124. That is, the smart contract in ledger 110 is configured to register the balances of all token holders. Thus, for transfers from Alice and Bob to Carrie, ledger 110 is configured to update the smart contract registry to include debits (from Alice and Bob) and credits (to Carrie). The wallet applications are configured to read the registry in ledger 110 to reflect each user's balance. The entries are generated by the wallet application (or a host associated with the wallet application, such as the token host 108) and / or ledger 110, and the entries represent transfers from Alice (i.e., sending 5 USDM) and Bob (i.e., sending 5 USDM) to Carrie (i.e., receiving 10 USDM).

[0029] Multiple options related to redemption can be implemented as part of different embodiments. In one example of redemption, as described above, when USDM is minted by parties 102, 104, and 106, each is configured to contribute an amount equal to the minted USDM to a central collateral fund for the consortium. The collateral account can be issued by any bank shown in FIG. 1, another bank, or potentially the token host 108. In this example, Bank A, Bank B, and Bank C each make a contribution, and the amount included in the collateral account is equal to all USDM minted under a unique smart contract. Then, as part of the redemption, Bank C, which is associated with Carrie, who is redeeming, for example, 10 USDM, is configured to initiate a transaction between the collateral account and Carrie's account. The transaction is coordinated through the payment processing network as necessary, the settlement file and settlement include the transaction (i.e., debiting the collateral account and crediting Carrie's account), and Bank C is configured to include an entry in its ledger 110 representing the burn of 10 USDM upon conversion.

[0030] In another redemption scenario, the consortium is configured to define redemption criteria, and tokens are redeemed in a manner consistent therewith. For minting tokens, the token host 108 is configured, for example, to track the number of tokens minted by different parties 102, 104, 106 as well as the number of tokens redeemed for the same party. The token host 108 is configured to coordinate redemptions based on the tracked numbers.

[0031] Specifically, in this example, Bank A is configured to mint 100 USDM and transfer 20 USDM to Alice, Bank B is configured to mint 200 USDM and transfer 5 USDM to Bob, and Bank C is configured to mint 1000 USDM and transfer 30 USDM to Carrie. Each bank may be configured to deposit funds corresponding to the minted tokens into an account or potentially identify a liability in other ways, etc. Consistent with the above, Carrie then transfers 12 USDM to Bob, which causes Bank C or Bank B (or an associated wallet application or host) to include an entry in ledger 110 indicating the transfer. Bob can then attempt to redeem the 17 USDM at Bank B.

[0032] Bank B is then configured to submit a redemption request to the token host 108.

[0033] The token host 108 is configured to determine which bank or combination of banks is funding the exchange based on defined criteria. Such criteria may include, for example, last in, first out (LIFO), first in, first out (FIFO), first to issue, percentage-based (such as the 100 / 200 / 1000 ratio exchange between different banks described above), max outstanding threshold, same jurisdiction, etc. In this example, the token host identifies Bank C as the exchanging bank based on one or more of the criteria described above. In this manner, the token host 108 is configured to initiate a transfer between Bank C and Bob's account at Bank B over a payment processing network (e.g., the MASTERCARD network, etc.) (e.g., via traditional ISO 8583 messaging, ISO 20022 messaging, etc.). Consistent with the above, Bank C is configured to include a debit entry in a settlement file associated with the payment processing network (e.g., between Bank C's account backing the previously issued token and Bob's account). Similarly, Bank B is configured to include a credit entry for Bob's account in its settlement file. Banks B and C are configured to submit their respective settlement files, and as part of the settlement, the processing network is configured to transfer funds from Bank C to Bank B (specifically, Bob's account at Bank B). The token host 108, or potentially Bank C, is configured to post an entry to the ledger 110, which will burn or redeem the associated 17 USDM.

[0034] In another example of convertibility, tokens are typically issued through a consortium of parties 102, 104, and 106 as USDM, which is not backed by users Alice, Bob, or Carrie's issuing bank, but is backed by a bank-specific token.

[0035] In particular, Bank A is configured to mint USDM-A under a first smart contract (on ledger 110) and deposit the funds into an account at Bank A associated with the minted token. In this exemplary embodiment, the token USDM-A is specific to Bank A and therefore transferable to users of Bank A (and may or may not be transferable to users associated with other banks, Banks B and C). Token host 108 is also configured to mint tokens (i.e., USDM), which are not directly backed by fiat currency but are instead backed by other tokens. Thus, when Alice wants to transfer 10 USDM-A to Bob, she requests USDM from Bank A or token host 108. Bank A and / or token host 108 are then configured to transfer the 10 USDM-A from Alice's wallet application (or more generally, her account) to the pool associated with the USDM via an entry in ledger 110. Bank A and / or the token host 108 is configured to mint 10 USDM and / or transfer 10 USDM to Alice's account, which is reflected in another entry in ledger 110. Alice is then allowed to transfer the 10 USDM to Bob, who is then allowed to exchange the USDM for a token specific to Bank B, i.e., USDM-B, which allows Bob to redeem the token at his bank, Bank B.

[0036] The token host 108 can be configured to impose conditions for banks' participation in the pool, whereby USDM-A, USDM-B, and USDM-C tokens can be burned and other tokens can be minted according to demand for particular tokens in the pool. The token host 108, in this regard, would be configured to burn tokens in a manner consistent with the above, whereby a transfer of funds from Bank A to the token host 108 (e.g., via a payment processing network, etc.) accompanies the burning of USDM-A, and a second transfer of those funds from the token host 108 to Bank B accompanies the minting of USDM-B, etc. Note that various different conditions can be selected and / or imposed to govern balances for different tokens in the pool. This can be done generally or based on specific user requests, etc.

[0037] In a third embodiment, the parties 102, 104, 106 and the token host 108 are configured to mint their own tokens. Accordingly, Bank A is configured to mint USDM-A tokens, Bank B is configured to mint USDM-B tokens, and Bank C is configured to mint USDM-C tokens. The token host 108 is also configured to mint USDM-H tokens. In this embodiment, the token host 108 is configured to maintain accounts with Bank A, Bank B, and Bank C. Consequently, the token host 108 is configured to purchase tokens from each bank; for example, Bank A is configured to mint 500 USDM-A for the token host 108 and debit the token host 108's account by $500. As described above, USDM-A is included on the ledger 110 under a smart contract for Bank A. The token host 108 is configured to request the same for Bank B and Bank C, and the token host 108 is configured to maintain a pool of tokens from participants, i.e., parties 102, 104, 106.

[0038] The token host 108 is also configured to mint USDM-H tokens, and does so under a smart contract specific to the token host 108 in response to requests from one or more users. In some examples, the token may be a "NAME" coin, which can be used by others via the token host 108 and may be, for example, a universal token. As an example, if Alice requests to convert 25 USDM-A into 25 USDM-H, she transfers the tokens from her account to the token host 108's pool. The token host 108 is configured to mint 25 USDM-H based on the transferred USDM-A and transfer the USDM-H to Alice. Each transfer is recorded in the ledger 110 under the appropriate smart contract. That is, Bank A's smart contract is for USDM-A, and the token host's smart contract is for USDM-H.

[0039] It should be noted that USDM-H is a universal token, and in this exemplary embodiment, is acceptable for a wide range of use cases native to ledger 110. That is, different parties, service providers, merchants, etc. can accept transfers of USDM-H as payment for goods, services, deposits, debits, etc., and the transfers can be indicated via entries in ledger 110, and receipts can proceed to redeem USDM-H or to further transfer or hold the tokens as disclosed herein.

[0040] Based on the above, note that Alice can then transfer the USDM-H to Bob, Carrie, etc., for one or more reasons. When Bob receives the 10 USDM-H from Alice, Bob can hold or transfer the USDM-H at his discretion in his wallet account. However, if he wishes to redeem the tokens at Bank B, Bob requests that the token host 108 convert the USDM-H to USDM-B (or to USDM-A for redemption as described above). Note that Bob can additionally or alternatively determine tokens that are common to him; Bob can request that the tokens be converted to USDM-A, for example, to group the tokens into a type and / or smart contract (e.g., tokens already held by the user, tokens preferred for trading, etc.). The particular token selected (e.g., USDM-H or USDM-A, etc.) may or may not be aligned with the party / bank with which the user has an account.

[0041] When Carrie receives the 10 USDM-H from Alice, as reflected in her wallet account, she can hold or transfer the USDM-H as she pleases. However, if she wishes to redeem the tokens at Bank C, Carrie requests that token host 108 convert the USDM-H into USDM-C. In response to the request, token host 108 transfers USDM-C tokens from the token pool to Carrie (e.g., via an entry in Bank C's smart contract on ledger 110) and is also configured to burn the incoming USDM-H (e.g., via an entry in the token host's smart contract on ledger 110). If there is a shortage of USDM-C in the token pool, the token host 108 is configured to request Bank C to mint additional USDM-C and debit the token host's account appropriately via a payment processing network (e.g., the MASTERCARD network) (e.g., via traditional ISO 8583 messaging, ISO 20022 messaging, etc.). Once USDM-C is added to the token pool, the token host 108 is configured to fulfill Carrie's request to convert USDM-H into USDM-C (as indicated in each smart contract on the ledger 110), so that Carrie can choose to redeem or hold the USDM-C, as described above.

[0042] Also, from time to time, the token host 108 may be configured to balance the token pool through the redemption of certain tokens and / or the purchase of other tokens based on one or more criteria, or to redeem certain tokens to maintain asset / liability levels, etc. In one or more embodiments, while Alice is transferring USDM-H to Bob, Alice may be allowed to transfer USDM-A or USDM-H or any other token contained in Alice's wallet account to Bob. In such embodiments, the token host 108 may be configured to effect conversions between different tokens upon request, even if they are not associated with USDM-H, etc.

[0043] It should be noted that while Figure 1 shows only three banks / parties 102-106, three users 114-118, one token host 108, and one ledger 110, other embodiments may involve any number of banks / parties, users, hosts, ledgers, etc. Furthermore, it should be noted that in connection with the above-described embodiments, different tokens, parties, etc. may be combined in one or more different ways while remaining within the scope of the present disclosure, thereby defining further embodiments of the concepts of the present disclosure.

[0044] FIG. 2 illustrates an exemplary computing device 200 for use within system 100. Computing device 200 may include, for example, one or more servers, workstations, personal computers, laptops, tablets, smartphones, point-of-sale (PoS) terminals, payment devices, etc. Furthermore, computing device 200 may include a single computing device or multiple computing devices located proximately or distributed across geographic locations, so long as the computing devices are specifically configured to function as disclosed herein. Notably, in the exemplary system 100 of FIG. 1, each of parties 102, 104, 106, token host 108, and ledger 108 may include or be implemented by a computing device such as computing device 200. Furthermore, communication devices 120, 122, and 124 may each be considered to be computing devices consistent with computing device 200. System 100 should not be construed as limited to the disclosed computing device 200, as different computing devices and / or computing device arrangements may be used. Additionally, different components and / or component arrangements may be used in other computing devices.

[0045] 2, a computing device 200 generally includes a processor 202 and memory 204 coupled to (in communication with) the processor 202. For example, the processor 202 may include one or more processing units (e.g., in a multi-core configuration) including, but not limited to, a central processing unit (CPU), a microcontroller, a reduced instruction set computer (RISC) processor, an application specific integrated circuit (ASIC), a logic circuit (PLC), a gate array, and / or any other circuit or processor capable of performing the functions of the present disclosure. The above examples are illustrative only and thus are not intended to limit the definition and / or meaning of a processor.

[0046] As described in this disclosure, memory 204 is one or more devices that allow for the storage and retrieval of executable instructions and / or other data, etc. Memory 204 may be configured to store, without limitation, tokens, ledger entries, and / or other types of data suitable for use in the present disclosure. Additionally, memory 204 may include, without limitation, one or more computer-readable media, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), solid-state devices (e.g., EMV chips, etc.), CD-ROMs, USB sticks, tapes, flash drives, hard disks, and / or any other type of volatile or non-volatile physical or tangible computer-readable media. It should be noted that memory 204 may include a variety of different memories. Furthermore, in various embodiments, computer-executable instructions may be stored in memory 204 for execution by processor 202, which causes processor 202 to perform one or more operations of the present disclosure (e.g., one or more operations described in method 300 or otherwise described in this disclosure), where memory 204 is a physical, tangible, and non-transitory computer-readable medium, and the instructions stored in memory 204 enable a computing device to operate as (or convert a computing device into) a special-purpose device configured to provide the features described in this disclosure.

[0047] Computing device 200 also includes a presentation unit 206 and an input device 208 coupled to (and in communication with) processor 202 .

[0048] Presentation unit 206 outputs information and / or data to a user (e.g., Alice, Bob, Carrie, etc.), for example, by displaying, audibly, and / or otherwise outputting the information and / or data. In some embodiments, presentation unit 206 may comprise a display device, and may display various interfaces (e.g., application screens, web pages, SMS messages, etc.) on the display device, computing device 200, to display such information and / or data, etc. Accordingly, presentation unit 206 may include presentation units such as, but not limited to, a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, an organic LED (OLED) display, an "electronic ink" display, a speaker, combinations thereof, etc. Additionally, presentation unit 206 may include multiple devices in some embodiments.

[0049] Input device(s) 208, when present in computing device 200, are configured to receive input from a user, including, for example, instructions regarding token transfers or token redemptions. The input device may include, but is not limited to, a keyboard, a mouse, a touch-sensitive panel (e.g., a touchpad or touchscreen), another computing device, and / or a voice input device. Additionally, in some exemplary embodiments, a touchscreen included in a tablet, smartphone, or similar device may operate as both presentation unit 206 and input device 208.

[0050] The illustrated computing device 200 further includes a network interface 210 coupled to (and in communication with) the processor 202 and the memory 240. The network interface 210 may include, but is not limited to, a wired network adapter, a wireless network adapter, a mobile adapter, or other device capable of communicating with, for example, the network 112 in the system 100 (e.g., the Internet, a private or public LAN, a WAN, a mobile network, a combination thereof, or other suitable network, etc.). In some exemplary embodiments, the processor 202 and one or more network interfaces may be integrated together.

[0051] 3 illustrates an exemplary method 300 for use in token management. The exemplary method 300 is described as being implemented in portions of system 100. Reference is also made to computing device 200. However, the method should not be construed as being limited to system 100 or computing device 200, as the method may be implemented in other systems and / or computing devices. Likewise, the systems and computing devices of the present disclosure should not be understood as being limited to exemplary method 300.

[0052] First, at S302, a request to redeem a first token is received from a user, such as Alice (e.g., user 114) (or a bank A (e.g., party 102) associated with Alice) at the token host 108. In this example, the first token comprises a common or universal token, USDM-H. The request may be received at the token host 108 via a wallet application in the communication device 118.

[0053] In response, at S304, the token host 108 identifies a bank associated with the user. For example, given that the first token is a USDM-H unique to the token host 108, the token host 108 identifies a bank associated with the user (e.g., Alice in this example), which is Bank A in this example. The bank can be identified based on data associated with the user or the content of the request to redeem the first token. In at least one exemplary embodiment, Alice can specifically indicate Bank A.

[0054] At S306, the token host 108 transfers the second token (USDM-A in this example) to Alice via / with ledger 110. In doing so, ledger 110 records an entry, specifically in a contract specific to USDM-A, indicating the transfer of the number of USDM-A to Alice (generally corresponding to the number of USDM-H being converted). In this context, Alice (or a wallet application or a host associated with the wallet application (e.g., Bank A, etc.)) causes ledger 110 to include an entry, specifically in a contract specific to USDM-H, indicating the transfer of USDM-H to token host 108 and / or the burning of USDM-H.

[0055] 3, the token host 108 can optionally determine, as indicated by the dashed line, at S305a, whether the token host 108 has sufficient USDM-A to fulfill the redemption request. If the second token (i.e., USDM-A in this example) is insufficient, the token host 108 purchases the second token from an identified bank, e.g., Bank A in this example, at S305b via a payment processing network (e.g., the MASTERCARD network) (e.g., via traditional ISO 8583 messaging, ISO 20022 messaging, etc.). The token host 108 then transfers the USDM-A to Alice at S306 via an entry in ledger 110, as described above, whereupon USDM-H is transferred or burned to the token host 108 via an entry in ledger 110.

[0056] Although FIG. 3 is described with reference to the token host 108, one or more steps included in the method 300 may be performed in whole or in part by the parties 102, 104, 106 in different embodiments of token management.

[0057] 4-5 illustrate additional example flows / methods that may be implemented by or through portions of system 100. However, the example flows in this disclosure should not be construed as limited to system 100 or computing device 200, as the example flows / methods may be implemented by other systems and / or computing devices while remaining within the scope of this disclosure. Likewise, the systems and computing devices of this disclosure should not be construed as limited to the example flows / methods shown in FIGS.

[0058] In the example flow of FIG. 4, a party, e.g., Bank A, issues an account specific to a user 114, e.g., Alice, containing $100 USD. Alice wishes to convert the $100 USD into 100 USDM (e.g., step 1). In response to Alice's request, Bank A mints tokens, e.g., USDM, via a token issuing service (e.g., token host 108), and the money is debited from Alice's account, issuing Alice 100 USDM (e.g., if each USDM is $1 USD) (e.g., step 2). The token issuing service then updates the tokens minted by Bank A and the USDM supply (e.g., in ledger 110) (e.g., step 3).

[0059] Next, Alice transfers some or all of the USDM from her wallet to another user (e.g., user 116, e.g., Bob) (e.g., step 4).

[0060] In turn, sometime later, Bob requests conversion of the USDM into fiat currency (e.g., $20 USD) with a party (e.g., Bank B, the party that issued Bob his account) (e.g., step 5). In response, Bank B requests clearing (e.g., step 6) through a convertible token issuance service (e.g., token host 108). Token host 108 requests clearing with another party (e.g., Bank X), which becomes the clearing bank for the particular USDM (e.g., step 7). Token host 108 initiates a transaction between Bank A and Bank X for the fiat currency equivalent of the converted USDM, e.g., via a clearing notice to each bank (e.g., via a payment processing network, etc.). Once the transaction clears between the banks, token host 108 updates ledger 110 to reflect the conversion of the USDM and the remaining total in the supply of USDM minted by Bank X (e.g., step 8).

[0061] In the exemplary flow shown in FIG. 5 , a party, for example, Bank A, issues an account specific to Alice (broadly, user 114), which contains $100 USD. In response to Alice's request for 100 USDM-A, Bank A mints 100 USDM-A (e.g., pursuant to a smart contract in ledger 110) and issues it to Alice (e.g., step 1). In doing so, an entry for USDM-A is created in ledger 110 indicating the transfer, which is reflected in a wallet application in communication device 120 (associated with Alice). The entry in ledger 110 includes the type (or issuer) of token (i.e., USDM-A), the number of tokens, and the holder (i.e., Alice). Bank A also debits Alice's account for $100 USD. As a result, Alice now has 100 USDM-A. In this example, for simplicity, each USDM-A can be equivalent to $1 USD.

[0062] Alice can then decide to transfer 5 USDM-A to Bob. Because Bob is not a customer or account holder of Bank A, the USDM-A cannot be transferred directly to Bob. Thus, in this example, Alice requests the conversion of 5 USDM-A to 5 USDM-H (e.g., step 2). Alice transfers tokens from her account to the token host 108. The token host 108 is configured to mint 5 USDM-H based on the transferred USDM-A and transfer the USDM-H to Alice. Each transfer is recorded in the ledger 110 under the appropriate smart contract; that is, Bank A's smart contract is related to USDM-A, and the token host's smart contract is related to USDM-H.

[0063] As noted above, it is important to note that USDM-H is a common token and, in this exemplary embodiment, is acceptable for a wide range of use cases that are native to ledger 110.

[0064] Alice can then transfer USDM-H to Bob (e.g., step 3). When Bob receives 5 USDM-H from Alice, Bob can hold or transfer USDM-H in his wallet account. As shown (e.g., in step 4), Bob can request that token host 108 convert USDM-H into USDM-B (i.e., a token associated with Bank B, which issued the account to Bob). Bob can then hold USDM-B in his wallet (e.g., step 5), as shown, or can exchange USDM-B for fiat currency at Bank B, which will be credited to Bob's account.

[0065] Note that the token host 108 can interact with Bank A, Bank B, and other banks to service tokens minted by them, and rules can be imposed on burning tokens, minting tokens, etc., and specific tokens can be used to fulfill customer requests (e.g., step 6).

[0066] Again, and as mentioned above, it should be understood that the functionality of the present disclosure may, in some embodiments, be described in computer-executable instructions stored on a computer-readable medium and executable by one or more processors. A computer-readable medium is a non-transitory computer-readable storage medium. By way of non-limiting example, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium usable to carry or store desired program code in the form of instructions or data structures and accessible by a computer. Combinations of the above are also included within the scope of computer-readable media.

[0067] It should be appreciated that one or more aspects of the present disclosure transform a general-purpose computing device into a special-purpose computing device when configured to perform the functions, methods and / or processes of the present disclosure.

[0068] As will be understood based on the above specification, the above-described embodiments of the present disclosure may be implemented using computer programming or engineering techniques (including computer software, firmware, hardware, and combinations or subsets thereof), and a technical effect may be achieved by: (a) receiving a request from a first user to redeem a first token having a first value, the first token being issued by a consortium of multiple parties; (b) in response to the request, identifying, by a computing device of a token host computing device, one of the multiple parties to settle the redemption for the first token based on one or more criteria; (c) initiating, by the computing device, a transfer of a second token specific to the one of the multiple parties to an account of the first user in exchange for the first token; or (d) receiving a request from a first user to redeem a first token having a first value, the first token being issued by a consortium of multiple parties; (e) in response to the request, identifying one of the multiple parties to settle the redemption for the first token based on one or more criteria, and (f) initiating a transfer of a first value from the one of the multiple parties to an account specific to the first user, or (g) converting the first token into a second token, the second token being minted by the one of the multiple parties, or (h) in response to a request to redeem a number of common tokens, for a user: (i) burning, by a token host computing device, the number of common tokens on a ledger as indicated in a first entry on the ledger, and (ii) transferring, by the computing device, a number of first tokens equal to the number of common tokens to the user as indicated in a second entry on the ledger;The first token is minted on the ledger by a party that issued the user's account.

[0069] The exemplary embodiments are provided so that the present disclosure will be thorough and fully convey the scope to those skilled in the art. Many specific details (e.g., specific components, devices, and methods) are set forth to provide a thorough understanding of the embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details are not necessarily implemented, that the exemplary embodiments may be embodied in many different forms, and that nothing should be construed as limiting the scope of the present disclosure. In some exemplary embodiments, well-known processes, well-known device structures, and well-known technologies are not disclosed in detail.

[0070] The terminology used in this disclosure is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used in this disclosure, the singular indefinite and definite articles may also be intended to include the plural unless the context clearly dictates otherwise. The terms "comprise," "including," "having," "having," and "having" indicate inclusion and specify the presence of stated features, objects, steps, operations, elements, and / or components. However, such terms do not exclude the presence or addition of one or more other features, objects, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations of the present disclosure should not be construed as necessarily requiring them to be performed in the particular order disclosed or illustrated, unless an order of performance is explicitly specified. It should be understood that additional or alternative steps may be implemented.

[0071] When a feature is "on," "related to," "connected," "coupled," "associated," "contained in," or "communicates" with another feature, the feature may be directly on, related to, connected to, coupled, associated with, contained in, or communicating with the other feature, or there may be intervening features. As used herein, the terms "and / or" and "at least one" include any and all combinations of one or more of the associated listed items.

[0072] Although terms such as first, second, third, etc. may be used in this disclosure to describe various features, these features should not be limited by these terms. These terms may be used solely to distinguish one feature from another. When used in this disclosure, "first," "second," and other numerical terms do not imply a sequence or order unless the context clearly dictates otherwise. Thus, a first feature of the present disclosure could be described as a second feature without departing from the teachings of the exemplary embodiments.

[0073] No claimed element is intended to be a means-plus-function within the meaning of 35 U.S.C. § 112(f) unless expressly recited using the phrase "means for" or unless recited in method claim format using the phrase "function for" or "step for."

[0074] The above disclosure of exemplary embodiments is provided for purposes of illustration and description. The disclosure is not exhaustive and is not intended to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment. Thus, such individual elements or features, even if explicitly shown and described, are interchangeable, where applicable, and can be used in selected embodiments. The same content may be modified in many ways. Such variations are not considered to depart from the disclosure. All such modifications are intended to be within the scope of the disclosure.

Claims

1. 1. A computer-implemented method for use in token management, the method comprising: receiving a request from a first user to redeem a first token having a first value, the first token being issued by a consortium of multiple parties; In response to the request, identifying, by a token host computing device, one of the plurality of parties to settle the redemption for the first token based on one or more criteria; and initiating, by the computing device, a transfer of a second token specific to the one of the plurality of parties to the first user's account in exchange for the first token.

2. 10. The computer-implemented method of claim 1, further comprising recording, by the computing device, an entry indicating redemption for the first token into a ledger associated with the first token.

3. 2. The computer-implemented method of claim 1, wherein the first tokens include a plurality of first tokens having the first value and the second tokens include a plurality of second tokens; the plurality of second tokens have second values; the first values ​​of the plurality of first tokens are equal to the second values; Computer-implemented methods.

4. 10. The computer-implemented method of claim 1 further comprising: determining, by the computing device, whether the host of the token includes the second token; purchasing the second tokens from the one of the plurality of parties prior to initiating the transfer of the second tokens to the account of the user; Computer-implemented methods.

5. 10. The computer-implemented method of claim 1, wherein the first token is associated with a ledger contract specific to a host of the token.

6. 6. The computer-implemented method of claim 5, wherein the one or more criteria are based on a percentage of tokens associated with each of the plurality of parties.

7. 2. The computer-implemented method of claim 1, wherein the one or more criteria relate to an order in which the first token is minted in relation to the second token.

8. 2. The computer-implemented method of claim 1, wherein initiating the transfer of the second token to the account of the first user comprises initiating the transfer via a payment processing network.

9. 1. A computer-implemented method for use in token management, the method comprising: receiving a request from a first user to redeem a first token having a first value, the first token being issued by a consortium of multiple parties; In response to the request, identifying, by a token host computing device, one of the plurality of parties to settle the redemption for the first token based on one or more criteria; converting the first token into a second token, the second token being minted by the one of the plurality of parties; and instructing, by the computing device, the one of the plurality of parties to transfer funds equivalent to the first value to an account specific to the first user.

10. 10. The computer-implemented method of claim 9, wherein the step of instructing the one of the plurality of parties to transfer funds includes instructing the one of the plurality of parties to include a debit entry in a settlement file for the first value, and instructing a second of the plurality of parties that issued the account to include a credit entry in the settlement file for the first value.

11. 10. The computer-implemented method of claim 9, wherein the first token comprises a plurality of tokens; The computer-implemented method, wherein the second token comprises a plurality of tokens.

12. 10. The computer-implemented method of claim 9, wherein instructing the one of the plurality of parties to transfer the funds comprises instructing the one of the plurality of parties to transfer the funds via a payment processing network.

13. 1. A computer-implemented method for use in token management, the method comprising: In response to a request to redeem a number of common tokens, burning, by a computing device of a host of the token, the number of common tokens on a ledger as indicated by a first entry on the ledger; transferring, by the computing device, to the user, as indicated in a second entry in the ledger, a number of first tokens equal to the number of common tokens, the first tokens being minted in the ledger by a party that issued the user's account; Computer-implemented methods.

14. 14. The computer-implemented method of claim 13, wherein the number of common tokens is issued by a consortium of multiple parties, the multiple parties including the party that issued the account for the user.

15. 14. The computer-implemented method of claim 13, further comprising: purchasing at least a portion of the number of first tokens from a first party based on an account issued to a host of the tokens at the first party, as indicated by a third entry in the ledger; 10. The computer-implemented method, wherein transferring the number of first tokens includes transferring the number of first tokens after receiving at least a portion of the number of first tokens from the first party.

Images