Method and system for managing payments and payment alternatives using a cryptocurrency system

Abstract

Embodiments of the present invention relate to methods and systems for effectively managing a digital currency system using a cryptocurrency scheme. The embodiments utilize a payment processor computer to manage entities in the digital currency system that have the right to generate, distribute, trade, and redeem digital currency units. In some embodiments, the digital currency may represent points in a loyalty program sponsored by an entity or organization. Transactions made using the digital currency and the rules for managing the digital currency can be tracked and maintained in a master ledger maintained by the payment processor computer and distributed as a sub-ledger to other entities within the digital currency system.

Description

[0001] This divisional application of the invention is a divisional application of the invention patent application with international application number PCT / US2016 / 060048, international filing date November 2, 2016, and national stage entry application number 201680071832.X in China, with the title "Methods and Systems for Managing Payments and Payment Alternatives Using a Cryptocurrency System".

[0002] Cross - reference to related applications

[0003] This patent application is a non - provisional application of U.S. Provisional Application No. 14 / 961,554 filed on December 7, 2015, and claims the benefit thereof, which provisional application is hereby incorporated by reference in its entirety for all purposes. Background of the Invention

[0004] The use of computing devices for transactions has increased significantly, making it increasingly easy for consumers to conduct e - commerce and online shopping using merchant websites and mobile applications. This has also led to a shift from paper - based payment schemes (e.g., exchanging physical currency or paper money for goods and services) to relying on electronic systems for currency exchange. Along with this shift, the number of payment alternatives for conducting transactions in addition to paper - based schemes has also increased, including but not limited to credit and debit card systems, temporary vouchers, loyalty / reward points, and other forms of digital or virtual currency (such as Bitcoin).

[0005] Incentive programs and loyalty programs are developed and managed by companies and financial institutions as a means of maintaining consumer loyalty. Incentives can be provided to consumers through the accumulation of transaction points. For example, consumers can exchange points for various goods and services offered by the issuer of the loyalty points. With the increase in the number of payment alternatives, the problem of how to manage these payment alternatives in an efficient manner has arisen.

[0006] In current solutions, consumers establish accounts on an account database (e.g., a financial institution) that contains points. As consumers conduct transactions, they earn points, which they can then use to shop or obtain other rewards. However, in the case where consumers participate in many different loyalty or reward programs, it may be necessary for consumers to establish separate accounts for each program. The infrastructure required to handle the proliferation of loyalty programs can lead to a large amount of unnecessary overhead in account management and, in addition, can cause friction for consumers due to over - burdening of network resources.

[0007] Therefore, there is a need for new and enhanced methods for managing digital currency systems that provide consumers with more efficient payment alternatives than current solutions.

[0008] The embodiments of the present invention individually and jointly address these and other problems. Summary of the Invention

[0009] Embodiments of the present invention relate to systems and methods for effectively managing a digital currency system using a cryptocurrency scheme. The embodiments utilize a payment processor computer to manage entities in the digital currency system that have the right to generate, distribute, trade, and redeem digital currency units. In some embodiments, the digital currency may represent points in a loyalty program sponsored by an entity or organization. Transactions made using the digital currency and the rules for managing the digital currency can be tracked and maintained in a master ledger maintained by the payment processor computer and distributed as sub-ledgers to other entities within the digital currency system.

[0010] One embodiment of the present invention relates to a method that includes receiving, by a processor computer, a request message for generating data elements from a distributor computer. The request message may be digitally signed using a first key associated with the distributor computer and includes a first quantity of data elements to be generated. The method further includes using a second key associated with the distributor computer to verify the request message to determine whether the distributor computer is authorized to generate the data elements. The method further includes generating a first data entry in a master ledger that includes the first quantity of data elements and sending a first update to a distributor sub-ledger of the distributor computer, the first update including the first data entry. The method further includes receiving a rule message from the distributor computer that is digitally signed using the first key associated with the distributor computer and includes rules for managing the use of the data elements. The method also includes using a second key associated with the distributor computer to verify the rule message. The method further includes updating the master ledger to include a second data entry for the rules and sending a second update to the distributor sub-ledger, the second update including the second data entry.

[0011] Another embodiment of the present invention relates to a server computer, comprising: a processor and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor to implement a method, the method comprising receiving, by a processor computer, a request message for generating data elements from a distributor computer. The request message may be digitally signed using a first key associated with the distributor computer and includes a first quantity of data elements to be generated. The method further comprises using a second key associated with the distributor computer to verify the request message to determine whether the distributor computer is authorized to generate data elements. The method further comprises generating a first data entry in a main ledger comprising the first quantity of data elements and sending a first update to a distributor sub-ledger of the distributor computer, the first update comprising the first data entry. The method further comprises receiving from the distributor computer a rule message digitally signed using the first key associated with the distributor computer and comprising rules for governing the use of the data elements. The method further comprises using a second key associated with the distributor computer to verify the rule message. The method further comprises updating the main ledger to include a second data entry for the rules and sending a second update to the distributor sub-ledger, the second update comprising the second data entry.

[0012] Another embodiment of the present invention relates to a method, comprising receiving, from a redeemer computer, a request message for redeeming a certain quantity of data elements to a distributor computer. The request message may be digitally signed using a first key associated with the redeemer computer and includes the quantity of data elements to be redeemed. The method further comprises using a second key associated with the redeemer computer to verify the request message. The method further comprises updating a main ledger to include a data entry indicating that a certain quantity of data elements have been redeemed to the distributor computer and initiating a settlement process using information of the redeemer computer stored in a profile database.

[0013] Another embodiment of the present invention relates to a server computer, comprising: a processor and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor to implement a method, the method comprising receiving, from a redeemer computer, a request message for redeeming a certain quantity of data elements to a distributor computer. The request message may be digitally signed using a first key associated with the redeemer computer and includes the quantity of data elements to be redeemed. The method further comprises using a second key associated with the redeemer computer to verify the request message. The method further comprises updating a main ledger to include a data entry indicating that a certain quantity of data elements have been redeemed to the distributor computer and initiating a settlement process using information of the redeemer computer stored in a profile database.

[0014] Although the above computers and methods relate to processor computers and systems, other embodiments of the present invention may relate to holder computing devices and methods performed by holder computing devices, redeemer computers and processes performed by redeemer computers, distributor computers and processes performed by distributor computers, and systems or methods including any combination of the above systems and methods.

[0015] These and other embodiments of the present invention are described in more detail below with reference to the accompanying drawings and the "Detailed Description". BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A block diagram of an exemplary system for generating and managing a digital currency system in accordance with an embodiment of the present invention is shown.

[0017] Figure 2 A detailed block diagram of a payment processor computer in accordance with an embodiment of the present invention is shown.

[0018] Figure 3 A flowchart of a method for registering and generating keys within a digital currency program in accordance with an embodiment of the present invention is shown.

[0019] Figure 4 A flowchart of a method for generating digital currency by an issuer in accordance with an embodiment of the present invention is shown.

[0020] Figure 5 A flowchart of a method for transferring digital currency between entities in accordance with an embodiment of the present invention is shown.

[0021] Figure 6 A flowchart of a method for a redeemer to redeem digital currency from an issuer of the digital currency in accordance with an embodiment of the present invention is shown.

[0022] Figure 7 An exemplary master ledger database diagram in accordance with an embodiment of the present invention is shown.

[0023] Figure 8 An exemplary block diagram of a computer device in accordance with an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0024] Before discussing embodiments of the present invention, a description of some terms may help to provide a better understanding of the present invention.

[0025] "Digital currency" can include a unit of value that can be used as a form of payment for transactions (including financial transactions). Digital currency can be currency that is electronically generated by a user computing device and stored on the user computing device. Digital currency can be represented by data elements (e.g., points, dollars, etc.) having a defined value or exchange rate, and can be or not be legal tender. In some embodiments, the defined value and exchange rate can be modified by the issuer of the digital currency at any time. If the digital currency is non-legal tender such as membership points, conventional currency forms (e.g., legal tender) can also be used to purchase the digital currency and generate the digital currency at a specific value. Generally, digital currency may not have a physical form of currency, but can be accessed through a software application such as a digital wallet or a mobile application on a user computing device (e.g., a mobile device).

[0026] "Data element" can include a data unit. In some embodiments, a data element can be a data unit of a digital currency system. A data element can represent points within the digital currency system, where the quantity of the data element represents the quantity of points. In some embodiments, a data element can also be referred to as a unit, credit point, or point.

[0027] "Master ledger" can include a compilation of data of previous transactions. The master ledger can be stored in a database and / or stored in a specific file structure. The master ledger can store data from any suitable quantity (e.g., all) of previous transactions performed using digital currency. Entries in the master ledger can include the date and time of the transaction, the transaction amount, and the transaction participants (e.g., the sender and recipient of the transaction amount). In some embodiments, the master ledger can be embodied by a blockchain, where each new block in the blockchain is determined algorithmically based on new transactions and previous blocks in the blockchain. In some embodiments, the master ledger can be stored and managed by a central processing computer (e.g., a payment processor computer).

[0028] A "sub-ledger" may include a subset of data in a master ledger. The sub-ledger may be stored in a database and / or in a specific file structure. The sub-ledger may store data from a subset of data of previous transactions executed using digital currency. Such data may include the date and time of the transaction, the transaction amount, and the participants in the transaction (e.g., the sender and recipient of the transaction amount). In some embodiments, the sub-ledger may be embodied by a blockchain, where each new block in the blockchain is algorithmically determined based on new transactions and previous blocks in the blockchain. In some embodiments, the sub-ledger may be stored and managed by a central processing computer (e.g., a payment processor computer) in a digital currency system. In some embodiments, other entities within the digital currency system may store a sub-ledger of the master ledger. Each sub-ledger may include entries from the master ledger related to a specific entity or a node associated with that entity. In some embodiments, only a specific entity may be able to view the contents of the sub-ledger. For example, only the participants in a transaction and the payment processor computer that processes the transaction may be able to view the sub-ledger entries for the transaction. In some embodiments, one or more nodes may store a read-only copy of the master ledger such that the master ledger is not altered by those specific nodes or entities.

[0029] A "data entry" may include an entry having information. A data entry may be a record of information. In some embodiments, each data entry may include pieces of information that evidence different events (e.g., transactions, rule creations). In some embodiments, a data entry may include information about a completed transaction, including the sender address, the recipient address, the transaction amount, etc.

[0030] A "digital signature" may include a mathematical technique for verifying the authenticity and integrity of a message. A digital signature may be a unique value generated from a message and a private key using a cryptographic algorithm. In some embodiments, the signature may be verified using a public key associated with the private key (as is known in the art). A digital signature may be a digital value, an alphanumeric value, or any other type of data including a graphical representation.

[0031] A "key" may include a piece of information that determines the functional output of a cryptographic algorithm or cipher.

[0032] A "hash function" may include a function that can map data of any size to data of a fixed size.

[0033] A "random number (nonce)" may include a random or pseudo-random value. In some embodiments, a random number may be any number that can be used only once. A random number may be used in a cipher as part of generating a hash function. In some embodiments, a random number may be a 32-bit field. However, in other embodiments, a random number may be less than or greater than 32 bits.

[0034] A "message" can include an electronic message that can convey information. In some embodiments, the electronic message can be in any suitable form, including an email, a Short Message Service (SMS) message, a Multimedia Message Service (MMS) message, a Hypertext Transfer Protocol (HTTP) request message, an ISO8583 message, a Transmission Control Protocol (TCP) packet, a web form submission. The message can be directed to any suitable location, such as an email address, a phone number, an Internet Protocol (IP) address, or a Uniform Resource Locator (URL). In some embodiments, the message can include a mixture of different message types, such as both an email message and an SMS message.

[0035] A "profile" can refer to information about an entity. In some embodiments, the profile can be a representation of information about an entity, including rights and restrictions, identification data, and authentication data. For example, the profile of an entity can include data indicating the type of role the entity has within a digital currency system. The profile can also be used to store a user's financial information. In some embodiments, the profile can be stored in a database and linked to an identifier associated with the entity related to the profile. An entity can have one or more profiles.

[0036] A "value token" can be an identifier that represents value. In some embodiments, the value token can have a value associated with it that allows the value token to be transferred from one entity to another entity. For example, as part of a transaction, the value token can be transferred from a first entity to a second entity, such as for point-of-sale payments, in exchange for other value, and for conversion to fiat currency.

[0037] A "payment processor computer" can include a server computer for payment processing. The payment processor computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and assemblages to service requests from one or more client computers. In some embodiments, the payment processor computer can operate multiple server computers. In such embodiments, each server computer can be configured to process transactions for a given region or to process a specific type of transaction based on transaction data. In some embodiments, each server computer can be configured to store a copy of the transaction master ledger.

[0038] In some embodiments, a payment processing server computer can exist within a payment processing network. The payment processing network can include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network can include VisaNet TM including VisaNet TMNetworks, including VisaNet, are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically, it includes an integrated payment system for processing authorization requests and a BaseII system for performing clearing and settlement services. The payment processing network can use any suitable wired or wireless network, including the Internet.

[0039] "Initiate" can include taking steps to start a process or include performing at least some initial steps in the process itself. For example, "initiating a settlement process by a processor computer using the financial information of a redeemer computer stored in a profile database" can refer to the actual process required to complete actions related to the settlement process. In some embodiments, "initiating a settlement process by a processor computer using the financial information of a redeemer computer stored in a profile database" can also include sending a message with instructions for performing the settlement process.

[0040] "Server computer" can include a powerful computer or a computer cluster. For example, a server computer can be a mainframe, a small computer cluster, or a group of servers that work like a unit. In one instance, a server computer can be a database server coupled to a web server. The server computer can be coupled to a database and can include any hardware, software, other logic, or a combination of the foregoing for servicing requests from one or more client computers. The server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to service requests from one or more client computers.

[0041] Embodiments of the present invention can relate to implementing a digital currency system using cryptocurrency payment network technology. In such embodiments, a payment processor computer can manage the rights and restrictions granted to entities within the digital currency system. Some nodes in the cryptocurrency payment network can be issuers authorized to issue and generate digital currency, while other nodes can be holders or redeemers authorized to use the digital currency for distribution and transactions. In some embodiments, a redemption node can redeem fiat currency with digital currency using the rules governing the digital currency.

[0042] I. System

[0043] Figure 1 A block diagram of an exemplary system 100 for generating and managing a digital currency system according to an embodiment of the present invention is shown. Figure 1 The system 100 in includes a holder A computing device 102, a holder B computing device 104, an issuer computer 106, a redeemer computer 108, and a payment processor computer 110. In Figure 1In the illustrated embodiments, a system and computers interact via one or more communication networks 112 (e.g., one or more of the Internet, private communication networks, and public communication networks). Each of these systems and computers can communicate operably with each other via any suitable communication protocol over any suitable communication medium, including the Internet. In some embodiments, an optional issuing partner computer 114 coupled to the issuer computer 106 can also interact with Figure 1 the illustrated systems and computers.

[0044] For simplicity of illustration, a specific number of components are shown in Figure 1 . However, it should be understood that embodiments of the present invention may include more than one of each type of component. Additionally, some embodiments of the present invention may include fewer or more components than Figure 1 all of the components shown. Thus, in Figure 1 , dashed lines are included to indicate optional features, which serve as a reminder that the number of these entities included in various embodiments is flexible.

[0045] The Holder A and Holder B computing devices 102 and 104 can take any suitable form. For example, suitable computing devices can be handheld and compact such that they can fit into a user's pocket. Examples of computing devices 102 and 104 can include any device capable of accessing the Internet or other suitable network. Specific examples of computing devices 102 and 104 include cellular or wireless telephones (e.g., smartphones), phablets, tablets, laptop computers, desktop computers, terminal computers, workstations, personal digital assistants (PDAs), physical cryptocurrency wallet hardware, pagers, portable computers, smart cards, wearable devices such as smartwatches, vehicles such as cars with telecommunication capabilities, and so on. In some embodiments of the present invention, the computing device associated with a holder and the corresponding payment device can be implemented by a single device (e.g., a mobile phone that can be used to conduct payment transactions).

[0046] Each of the computing devices 102 and 104 can include a processor and a computer-readable medium coupled to the processor. The computer-readable medium can include code executable by the processor for performing the functions described herein. The computing devices 102 and 104 can transmit data to the issuer computer 106, the redeemer computer 108, the payment processor computer 110, and to each other via the communication network 112.

[0047] In some embodiments, each of computing devices 102 and 104 may include a mobile wallet (102a and 104a) (or mobile wallet software such as a mobile wallet application), a private key (102b and 104b) (e.g., a private cryptographic key), and a sub-ledger (102c and 104c).

[0048] The Holder A mobile wallet 102a associated with the Holder A computing device 102 may be a storage application configured to store and maintain data. In some embodiments, the mobile wallet may store data indicating digital currency obtained from the issuer computer 106 (or another entity within the system 100). The mobile wallet 104a associated with the Holder B computing device 104 may also contain digital currency obtained from the issuer computer 106 (or another entity within the system 100). In some embodiments, the mobile wallets (102a and 104a) may store user profile information, payment information, bank account information, etc. The mobile wallets 102a and 104a may be used for a variety of transactions, such as but not limited to e-commerce, money transfer / personal payment, mobile commerce, near-field payment, etc., for retail shopping, digital goods purchase, and transferring funds between users.

[0049] As part of the registration process in the system 100, the Holder A private key 102b associated with the Holder A computing device 102 may be obtained from the payment processor computer 110. The Holder A private key 102b may be a digital or alphanumeric value and may be generated using an algorithm. The Holder A private key 102b may be part of a key pair that includes the corresponding Holder A public key. In some embodiments, the Holder A private key 102b may be used to digitally sign a message, while the Holder A public key associated with the Holder A private key 102b may be used to verify the digital signature associated with the message. By encrypting the message with the Holder A private key 102b, the message may be considered to be digitally signed. It can be ensured that only the entity or individual having the Holder A private key 102b can encrypt the message, so that when the Holder A public key can be used to decrypt the message, it is verified that the encryptor and sender of the message are Holder A.

[0050] In some embodiments, with reference to Figure 2 , when a request to register with the system 100 is received from the Holder A computing device 102, the key generation module 110b-2 in the payment processor computer 110 may generate a public key / private key pair for the Holder A computing device 102. Similar operations may be performed when a request is received from the Holder B computing device 104.

[0051] The Holder A sub-ledger 102c associated with the Holder A computing device 102 may include a subset of the ledger entries contained in the master ledger database 110c stored in the payment processor computer 110. In some embodiments, the subset of ledger entries included in the Holder A sub-ledger 102c may be ledger entries related to transactions involving the Holder A computing device 102, digital currencies stored in the Holder A mobile wallet 102a, and any associated rules for managing the digital currencies stored in the Holder A mobile wallet 102a. In such embodiments, the Holder A sub-ledger 102c may not include transactions not involving the Holder A computing device 102. In some embodiments, the subset of ledger entries in the Holder A sub-ledger 102c may be read-only entries that cannot be changed by a user associated with the Holder A computing device 102.

[0052] The Holder B computing device 104 may include a Holder B mobile wallet 104a for storing and maintaining digital currencies; a Holder B private key 104b for encrypting messages; and a Holder B sub-ledger 104c for storing transaction records and rules related to the Holder B computing device 104. Additional details of the Holder B mobile wallet 104a, the Holder B private key 104b, and the Holder B sub-ledger 104c may be found in the section previously discussing the Holder A computing device 102.

[0053] In some embodiments, each of the issuer computer 106 and the redeemer computer 108 may be a computer associated with an independent entity. For example, the issuer computer 106 may be associated with a first entity (e.g., a first merchant), while the redeemer computer 108 may be associated with a second entity (e.g., a second merchant). The issuer computer 106 and the redeemer computer 108 may each include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor for performing the functions described herein.

[0054] As described above, the system 100 may include an issuer computer 106 and a redeemer computer 108 communicating via a communication network 112. In some embodiments, each of the issuer computer 106 and the redeemer computer 108 may be granted the right and ability to participate in the system 100 by the payment processor computer 110.

[0055] The issuer computer 106 may include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor for performing the functions described herein. The issuer computer 106 may be an entity capable of generating and distributing digital currency. In some embodiments, the issuer computer may generate more than one type of digital currency. The digital currency held by the issuer computer 106 may be included in the issuer mobile wallet 106a. In some embodiments, the issuer computer 106 may be a distributor computer.

[0056] The redeemer computer 108 may include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor for performing the functions described herein. The redeemer computer 108 may be an entity capable of receiving digital currency and returning the digital currency to the issuer computer 106 in exchange for fiat currency (or alternative valuable unit). The amount of fiat currency received by the redeemer computer 108 may be based on the quantity of digital currency returned, the previously determined exchange rate between the digital currency and fiat currency, and / or based on a contract agreement between the issuer computer 106 and the redeemer computer 108. The digital currency held by the redeemer computer 108 may be included in the redeemer mobile wallet 108a.

[0057] In some embodiments, each of the issuer computer 106 and the redeemer computer 108 may maintain a sub-ledger 106c and 108c of transactions performed using the digital currency and the rules established for the digital currency in the system 100. In some embodiments, the sub-ledgers 106c and 108c may include a list of transactions with each entry, including the sender address, recipient address, and quantity of digital currency for each transaction. In some embodiments, each sub-ledger 106c and 108c may only include entries related to the transactions performed by its respective computer. For example, the redeemer sub-ledger 108c may only store entries from the master ledger database 110c related to transactions involving the redeemer computer 108.

[0058] In some embodiments, the issuer sub-ledger 106c may include a record of all transactions ever performed using the digital currency issued by the issuer associated with the issuer computer 106, and may be a read-only copy of the master ledger database 110c stored in the payment processor computer 110. In such an embodiment, the issuer computer 106 may store a read-only copy of the master ledger database 110c for audit purposes in order to know all transactions involving the digital currency generated and distributed by the issuer computer 106.

[0059] In some embodiments, the storage sub-ledger may be optional. For example, in some embodiments, only some entities in system 100 may have a sub-ledger. In other embodiments, all entities in system 100 may have a sub-ledger, or none of the entities may have a sub-ledger. In such embodiments, an entity may request the generation of a sub-ledger by the payment processor computer 110 through a subscription process. The payment processor computer 110 may not generate any sub-ledgers unless it receives a request from an entity in system 100 and may only maintain the master ledger database 110c.

[0060] Figure 2 A detailed block diagram of the payment processor computer 110 according to an embodiment of the present invention is shown. In some embodiments, the payment processor computer 110 may be associated with or operated by a payment processing system. The payment processor computer 110 may include a processor 110a and a computer-readable medium 110b coupled to the processor 110a, and the computer-readable medium 110b includes code executable by the processor 110a for performing the functions described herein.

[0061] The computer-readable medium 110b may include code for multiple modules, including an authentication module 110b-1, a key generation module 110b-2, a transaction verification module 110b-3, and a data output module 110b-4.

[0062] The processor 110a and the authentication module 110b-1 may be configured jointly with each other to perform an authentication process. The authentication process may include determining whether a request message received from a computer is from an entity that should be granted the rights of an issuer (able to generate and distribute digital currency), a redeemer (able to receive digital currency and exchange digital currency for fiat currency with the issuer), or a holder (able to conduct transactions using digital currency). In some embodiments, a first entity may have multiple rights such that it can generate a first digital currency and use or exchange a second digital currency generated by a second entity to conduct a transaction. The rights granted to an entity may be determined based on the identification data of the entity in the request message or based on a contract agreement.

[0063] In some embodiments, the authentication process may further include authenticating a request message from an entity in system 100 to determine whether the node is an issuer, a holder, or a redeemer. In such an embodiment, processor 110a and authentication module 110b-1 may decrypt the message by using the second key of the stored key pair (e.g., the public key of the sender) to evaluate the received message that is digitally signed using the first key of the key pair (e.g., the private key of the sender). By decrypting the received message by verifying the digital signature of the received message using the second key of the sender, processor 110a and verification module 110b-1 may determine the authenticity of the message from the holder of the corresponding first key. When processor 110a and authentication module 110b-1 determine that a request message is received from a verified entity within the system, processor 110a and authentication module 110b-1 may determine the role (e.g., issuer, holder, redeemer) of the entity corresponding to the entity that sent the request message.

[0064] Processor 110a and key generator module 110b-2 in payment processor computer 110 may be configured to generate digital certificates (including public / private keys) and distribute them to each entity as part of the registration process to allow the entity to function in system 100. In some embodiments, the first key of the key pair (e.g., the public key) may be sent to the entity associated with the key, while the second key of the key pair (e.g., the private key) may be stored in the entity profile in entity profile database 110d at payment processor computer 110. The key pair may be used to identify the entity as an issuer, a holder, a redeemer, or an issuing partner, such that when the entity sends a request to generate or issue digital currency, payment processor computer 110 may determine whether the entity is an issuer authorized to generate and issue digital currency or whether the entity is another entity not authorized to generate or issue digital currency. In some embodiments, the key pair may be an asymmetric key pair. In embodiments of the present invention, a symmetric key pair may also be used. However, in other embodiments, any other suitable algorithm may be used to generate the key pair.

[0065] In some embodiments, the key pair may be an asymmetric key pair such that the public key may be used to encrypt a message sent from the entity to payment processor computer 110, and the corresponding private key of the entity may be used by payment processor computer 110 to decrypt the message.

[0066] The key pair may be generated by payment processor computer 110 in response to a request message from an entity (e.g., issuer computer 106) to create a digital currency (e.g., points) system and designate it as an entity in system 100 having the right to generate and distribute digital currency.

[0067] The processor 110a and the transaction verification module 110b-3 can be configured to evaluate a transaction message received from an entity in the system 100 and determine whether the transaction included in the transaction message is valid. The processor 110a and the transaction verification module 110b-3 can also be configured to generate a ledger entry in the main ledger database 110c (stored in the data memory) indicating that the transaction has been approved in response to determining that the transaction has been verified. In some embodiments, the processor 110a and the transaction verification module 110b-3 can also be configured to evaluate transaction messages related to generating digital currency, redeeming digital currency, and establishing rules associated with the generated digital currency.

[0068] In some embodiments, the payment processor computer 110 can receive a transaction message from one or more entities involved in a transaction. For example, for a transaction that transfers digital currency (e.g., points) from the issuer mobile wallet 106a to the holder A mobile wallet 102a, the processor 110a and the transaction verification module 110b-3 can receive a transaction message indicating that the transaction has occurred. The transaction message can be sent by the issuer computer 106 and / or the holder A computing device 102.

[0069] The processor 110a and the data output module 110b-4 can be configured to generate a message and send it to the holder computing devices 102 and 104, the issuer computer 106, and the redeemer computer 108. In response to a received request message for generating a key pair, and / or a request message indicating that an entity is requesting to generate, distribute, trade, or redeem a certain amount of digital currency, the data output module 150b-4 can generate a response message and send the response message to the entity. In other embodiments, in the case where the request message is a request to generate digital currency, the response message generated and sent by the data output module 150b-4 can include whether the entity sending the request message is the issuer and is authorized to issue and generate digital currency.

[0070] In some embodiments, the payment processor computer 110 can be coupled to the main ledger database 110c and the entity profile database 110d.

[0071] The main ledger database 110c can be or include a distributed ledger that includes entries for all transactions that occur between various entities within the system 100. The main ledger database 110c can include at least two types of entries: transaction entries and rule entries.

[0072] A transaction entry can be a record of a change in digital currency ownership, such as when an issuer associated with the issuer computer 106 issues digital currency to a holder associated with the holder A computing device 102, or when a holder associated with the holder A computing device 102 transfers a certain amount of digital currency to a redeemer computer 108 as part of a transaction.

[0073] A rule entry can be a record that indicates rules associated with the use of a particular digital currency. Rules that can be stored in a rule entry can include rules that govern the redemption and / or transfer of digital currency, the exchange rate of digital currency, and the start / end date of the rule. In some embodiments, the rules can define the expiration date of a data element, the effective date of a data element, the finite time value of a data element, restrictions on their use (based on geographical location), exchange rate or conversion rate, restrictions on the entities that can use or accept the data element. In some embodiments, one or more rules can be associated with a data element.

[0074] In some embodiments, each ledger entry in the master ledger database 110c can represent a single event (e.g., a transaction, a rule definition) executed within the digital currency system. In some embodiments, each ledger entry can be recorded in the master ledger database 110c in the order in which the payment processor computer 110 receives the event. Each ledger entry can be appended to the master ledger database 110c by cryptographically signing the ledger entry using a new ledger entry and a previous ledger entry in the master ledger database 110c.

[0075] The entity profile database 110d can store profiles of each entity or node within the system 100. The profile of each entity can contain a copy of the private key / public key that was previously sent to the entity. The profile can also include information about the entity and the rights and restrictions associated with the entity (e.g., whether the entity is an issuer, a holder, and / or a redeemer).

[0076] In some embodiments, the profile of each entity can also store financial information associated with the entity (e.g., financial institution name, bank identification number, account number). In such embodiments, the financial information can be used as part of the redemption process between the redeemer computer 108 and the issuer computer 102. For example, when the redeemer computer 108 attempts to redeem fiat currency with digital currency from the issuer computer 102, the financial information can be retrieved and used to perform a fund transfer from the issuer computer 106 to the redeemer computer 108.

[0077] In some embodiments, the issuing partner computer 114 may be associated with a user or entity that has a contractual relationship with the issuer computer 106 that generates digital currency. In such an embodiment, the issuing partner computer 114 may receive a certain amount of digital currency from the issuer computer 106 for distribution to other entities in the system 100 on behalf of the issuer computer 106. The issuing partner computer 114 may include a partner mobile wallet 114a for storing and maintaining digital currency, a partner private key 114b for encrypting messages, and a partner sub-ledger 114c for storing records of transactions related to the issuing partner computer 114. Other details of the partner mobile wallet 114a, the partner private key 114b, and the partner sub-ledger 114c can be found in the section previously discussing the holder A computing device 102.

[0078] II. Method

[0079] A. Main ledger and sub-ledger

[0080] In addition to all the rules governing digital currency, embodiments of the present invention utilize a main ledger database 110c stored in the payment processor computer 110 to store and maintain records of all transactions related to digital currency.

[0081] The main ledger database 110c may include two types of entries: transaction entries and rule entries. Transaction entries may be records indicating changes in digital currency ownership, such as when an issuer associated with the issuer computer 106 issues digital currency to a holder associated with the holder A computing device 102, or when a holder associated with the holder A computing device 102 transfers a certain amount of digital currency to a redeemer computer 108 as part of a transaction. In some embodiments, the transaction entries for a particular transaction may be confidential to the entities participating in that particular transaction and the payment processor computer 110. In some embodiments, when the rules do not change over time, the transaction entries may include one or more rules regarding the digital currency.

[0082] Rule entries may be records indicating rules associated with the use of a particular digital currency that may change over time (such as an exchange rate). The rules that may be stored in the rule entries may include rules governing the redemption and / or transfer of digital currency, the exchange rate of the digital currency (such as the exchange rate between digital currency and fiat currency), and the start / end dates applicable to the stored rules. Rules may also be used to outline agreements reached between entities in the digital currency system.

[0083] In some embodiments, when a rule needs to be changed, a new rule entry in the main ledger database 110c may be made effective. In such a case, the previously replaced rule will be locked and will not apply to future transactions.

[0084] When generating a new ledger entry, depending on the parties to the new ledger entry and the purpose of the new ledger entry, the new ledger entry can be signed and / or encrypted. A transaction can be signed by two participants in the transaction or encrypted so that only the two participants can access the transaction details in the body of the ledger entry. Partner agreement rules (e.g., between an issuer and a redeemer) can be signed and encrypted by the issuer and the redeemer. Public rule entries can be signed only by the issuer and are generally not encrypted. An exchange rate related to a transaction between a holder and a redeemer can be signed by the redeemer. If the exchange rate rule requires approval, the new ledger entry can also be signed by the issuer.

[0085] In some embodiments, the master ledger database 110c stored in the payment processor computer 110 can be updated only by the payment processor computer 110. A read-only copy of the master ledger database 110c can be distributed as a sub-ledger. For example, the issuer computer 106 can store an issuer sub-ledger 106c, which can include all the entries contained in the master ledger database 110c. In such an embodiment, as the originator and responsible party of the digital currency, the issuer computer 106 may need to know all aspects of the events (e.g., transactions and rules). In contrast, other entities in the digital currency system (e.g., holders, redeemers) may not need or may not wish to maintain records as detailed as the master ledger database 110c. In such an embodiment, the holder computer and the redeemer computer can store a holder sub-ledger (102c and 104c) and a redeemer sub-ledger 108c, respectively. These sub-ledgers can also be read-only copies, but can include fewer ledger entries than the full master ledger database 110c or the issuer sub-ledger 106c. In an embodiment of the present invention, each sub-ledger can provide an entity with the data (e.g., ledger entries) they may need to verify their own activities.

[0086] The sub-ledger can be encrypted so that only an entity having the sub-ledger and the private key can decrypt their own sub-ledger. For example, the holder A computing device 102 can use the holder A private key 102b to decrypt the holder A sub-ledger 102c. All sub-ledgers other than the public sub-ledger can be encrypted so that only the entity associated with a particular sub-ledger can access the particular sub-ledger.

[0087] In some embodiments, when a transaction has been verified by the payment processor computer 110 and a new ledger entry is added to the master ledger database 110c, the payment processor computer 110 may copy the new ledger entry from the master ledger database 110c to generate an entry that can be distributed to the sub-ledgers. Then, the payment processor computer 110 may use the new ledger entry in the master ledger database 110c and a random number (i.e., a 32-bit field with a random or pseudo-random value) to generate a hash. Then, as the entity that has copied the new ledger entry, the payment processor computer 110 may digitally sign the copied ledger entry. Then, the signed copied ledger may be distributed to the sub-ledgers of the entities involved in the transaction either through a publish / subscribe mechanism or manually by the entity.

[0088] B. Establishment and Registration of a Digital Currency System

[0089] Figure 3 A flowchart showing a method for registration and key generation within a digital currency scheme according to an embodiment of the present invention is shown. Although Figure 3 two holder computing devices (102 and 104), a single issuer computer 106, and a single redeemer computer 108 are depicted (similarly applicable to other subsequently depicted flowcharts), in other embodiments, there may be fewer or more such components.

[0090] In step 302, the issuer computer 106 sends a request message to create a digital currency system to the payment processor computer 110. The request message may be sent to the payment processor computer 110 via the communication network 112 using an appropriate communication channel and communication protocol. In some embodiments, when the payment processor computer 110 receives the request message, the payment processor computer 110 may determine the identity of the issuer computer 106 that sent the request message.

[0091] In some embodiments, the issuer computer 106 may be associated with an entity such as a merchant or a financial institution that is requesting to create a digital currency scheme using data elements (e.g., points) associated with a certain value. The value associated with the data element may be defined by one or more rules created by the issuer computer 106. The request message from the issuer computer 106 may also include a request to designate itself as the issuer within the digital currency system. In such an embodiment, the payment processor computer 110 may evaluate a merchant identifier (e.g., merchant identification number, merchant name) or a bank identification number (BIN) associated with the request message to determine whether the issuer computer 106 should be designated as the issuer.

[0092] In step 304, the payment processor computer 110 may create a master ledger database 110c associated with the digital currency system and generate a public key / private key pair for the issuer computer 106. When the payment processor computer 110 determines that the issuer computer 106 is a valid issuer, the payment processor computer 110 may initiate the process of establishing a digital currency system for the issuer computer 106.

[0093] Once the payment processor computer 110 determines that the issuer computer 106 can be designated as the issuer of the digital currency system, the payment processor computer 110 may generate a unique digital certificate and key pair for the issuer computer 106. In some embodiments, an asymmetric key pair algorithm may be used to generate the first key and the second key. However, as will be understood by those of ordinary skill in the art, the first key and the second key may also be generated using other means. In some embodiments, the keys of the key pair may be numeric or alphanumeric values. In some embodiments, the first key and the second key may be associated with the profile of the issuer computer 106 stored in the entity profile database 110d.

[0094] In some embodiments, the key pair may functionally be similar to a traditional public key and private key pair, with the first key corresponding to the public key. However, in some embodiments, the first key may be different from a typical public key in that the first key cannot be made public or broadcast to any other entity or computer other than the entity associated with the key pair. In such embodiments, the first key may be encrypted before being sent to the issuer computer 106 via the communication network 112 to ensure that if the first key is intercepted, it cannot be used unless the interceptor has the appropriate decryption key. The issuer computer 106 may use the first key to prove to the payment processor computer 110 that the issuer computer 106 is the issuer and thus has the right to generate and distribute digital currency. In some embodiments, there may be multiple issuer computers acting as issuers, each associated with a different digital currency. In such embodiments, the above process may be repeated for each such additional issuer computer.

[0095] The payment processor computer 110 may also generate the master ledger database 110c of the digital currency system. In some embodiments, the digital currency system may have only one master ledger database 110c.

[0096] In other embodiments, the payment processor computer 110 may store multiple master ledger databases 110c. In such embodiments, each copy of the master ledger database 110c stored by the payment processor computer 110 may be stored on a different server computer.

[0097] In some embodiments, the payment processor computer 110 may generate a ledger entry 110c-1 indicating that the issuer computer 106 is registered in the digital currency system, as Figure 7 shown. In some embodiments, the ledger entry 110c-1 indicating that the issuer computer 106 is registered may be an indication that the issuer computer 106 is responsible for the digital currency system. In some embodiments, the ledger entry 110c-1 may be entered as the first data entry in the master ledger database 110c.

[0098] In some embodiments, the ledger entry 110c-1 may be similar to a common rule and may be digitally signed using the private key of the issuer computer 110c. In this way, the public key of the issuer computer 110c may be used to verify the ledger entry 110c-1. In some embodiments, the ledger entry 110c-1 may also be signed by the payment processor computer 110 to indicate that the ledger entry 110c-1 has been processed and verified by the payment processor computer 110.

[0099] In step 306, the payment processor computer 110 may send a key pair (e.g., a public key and a private key) and the issuer sub-ledger 106c to the issuer computer 106. In some embodiments, the issuer sub-ledger 106c may be a read-only copy of the master ledger database 110c stored in the payment processor computer 110. In such an embodiment, the payment processor computer 110 may send all entries of the master ledger database 110c to the issuer computer 106. In other embodiments, the issuer sub-ledger 106c may include a subset of the entries in the master ledger database 110c. For example, in some embodiments, once the issuer computer 106 has distributed digital currency, the issuer sub-ledger 106c may include only the ledger entries related to the rules for managing the digital currency. For example, this may include rules specifying how the redeemer computer 108 can redeem digital currency from the issuer computer 110.

[0100] In some embodiments, instead of sending entries from the master ledger database 110c to the issuer computer 106, the payment processor computer 110 may provide information to the issuer computer 106 to allow an application running the issuer sub-ledger 106c to subscribe to receive messages from the payment processor computer 110 containing updates to the issuer sub-ledger 106c when changes are made to the master ledger database 110c. In such an embodiment, changes to the master ledger database 110c may be pushed to the issuer sub-ledger 106c.

[0101] In some embodiments, after generating a first data entry in the main ledger database 110c indicating that the issuer computer 106 has been registered, the payment processor computer 110 may send a first update to the issuer sub-ledger 106c, the first update including the first data entry. In some embodiments, the payment processor computer 110 may copy the first data entry from the main ledger database 110c. Then, the payment processor computer 110 may use the first data entry in the main ledger database 110c and a random number to generate a hash to generate the first update. Then, the payment processor computer 110 may digitally sign the first update before transmitting the first update to the issuer computer 106.

[0102] In some embodiments, the issuer sub-ledger 106c may be created at any time after the payment processor computer 110 generates a private key and a public key for the issuer computer 106 and before any transactions. For example, the issuer sub-ledger 106c may not be created until the issuer computer 106 performs an initial transaction (such as a point generation process). This may also apply to other entities in the system 100 (e.g., the holder A sub-ledger 102c may not be created until the issuer computer 106 issues points to holder A).

[0103] In step 308, the payment processor computer 110 may receive a request message requesting to generate a public key / private key for an additional entity to be registered in the digital currency system. The request message may be sent to the payment processor computer 110 via the communication network 112 using an appropriate communication channel and communication protocol. In some embodiments, when the payment processor computer 110 receives the request message, the payment processor computer 110 may determine the identity of the requester that sent the request message. For example, the payment processor computer 110 may receive requests from the holder A computing device 102, the holder B computing device 104, and the redeemer computer 108. The requests from the entities may indicate the type of role each entity requests to play within the digital currency system. For example, a request from the holder A computing device may request to be a holder within the digital currency system.

[0104] In some embodiments, the requests from the holder A computing device 102, the holder B computing device 104, and the redeemer computer 108 may include an indicator that the entity is requesting to participate in a program created by the issuer computer 106. For example, the request may include an identifier associated with the issuer computer 106 or the system (e.g., the identifier of the main ledger database 110c of a specific program). In such embodiments, the issuer computer 106 may distribute the identifier only to those entities that it authorizes to join its program.

[0105] In step 310, the payment processor computer 110 can generate a unique public / private key pair for each of the Holder A computing device 102, the Holder B computing device 104, and the redeemer computer 108. The payment processor computer 110 can also generate a ledger entry for each entity joining the digital currency system. This process can be performed in a manner similar to that described above for the issuer computer 106. In some embodiments, the payment processor computer 110 can generate key pairs for other entities based on the request received in step 308.

[0106] In some embodiments, the payment processor computer 110 can generate ledger entries (as Figure 7 shown) to indicate that the Holder A computing device 102 (ledger entry 110c-2), the Holder B computing device 104 (ledger entry 110c-3), and the redeemer computer 108 (ledger entry 110c-4) have joined the digital currency system. In some embodiments, the ledger entries (110c-2, 110c-3, and 110c-4) can be signed using the private key of the issuer computer 106 and the private key of the corresponding entity (e.g., ledger entry 110c-2 is signed using the private keys associated with the issuer computer 106 and the Holder A computing device 102). In some embodiments, the ledger entry 110c-2 can also be signed by the payment processor computer 110 to indicate that the ledger entry 110c-2 has been processed by the payment processor computer 110.

[0107] In some embodiments, hash techniques can be used to append the ledger entries indicating that the entities are registered to the main ledger database 110c. For example, when a new ledger entry is to be appended to the main ledger database 110c, the hash of the previous ledger entry (e.g., ledger entry 110c-1) and optionally the hashes of all other previous ledger entries can be combined with the hash of the new ledger entry (e.g., ledger entry 110c-2). In such embodiments, using the hash of the previous ledger entry allows the system to maintain the sequence of ledger entries, which can prevent the tampering of previous entries.

[0108] In step 312, the payment processor computer 110 may transmit the generated private key to the corresponding Holder A computing device 102, Holder B computing device 104, and redeemer computer 108. The payment processor computer 110 may also transmit appropriate sub-ledger entries to each of the Holder A computing device 102, Holder B computing device 104, and redeemer computer 108. In some embodiments, the sub-ledger entries sent to each of the Holder A computing device 102, Holder B computing device 104, and redeemer computer 108 may be different. In such embodiments, each entity may only receive the ledger entries related to that entity from the main ledger database 110c. For example, the Holder A sub-ledger 102A may only include the ledger entries of the transactions in which the Holder A computing device 102 participates and the rules applicable to the digital currency contained in the Holder A mobile wallet 102a.

[0109] In some embodiments, instead of sending entries from the main ledger database 110c to the Holder A computing device 102, Holder B computing device 104, and redeemer computer 108, the payment processor computer 110 may provide information to the entities to allow the applications running their respective sub-ledgers (102c, 104c, and 108c) to subscribe to receive messages from the payment processor computer 110 containing updates to their respective sub-ledgers when the main ledger database 110c is modified. In such embodiments, the first update and the second update may be automatically sent to the issuer sub-ledger 108 based on a predetermined schedule.

[0110] Once the issuer computer 106, Holder A computing device 102, Holder B computing device 104, and redeemer computer 108 have been established, the digital currency system may be configured to operate. In some embodiments, additional entities may be added to or removed from the digital currency system at any time, and any of the above steps may be performed again by the payment processor computer 110.

[0111] C. Generating Digital Currency

[0112] Figure 4 FIG. 400 is a flowchart showing a method for an issuer to generate digital currency according to an embodiment of the present invention.

[0113] In step 402, the issuer computer 106 may send a request message for creating data elements (e.g., points) of the digital currency system, and the payment processor computer 110 may then receive the request message via the communication network 112. In some embodiments, the request message may also include a first quantity of data elements to be generated. The request message itself may also be encrypted by the issuer computer 106 before being sent to the payment processor computer 110.

[0114] In some embodiments, the request message may be digitally signed using a private key associated with the issuer computer 106 that was previously generated by the payment processor computer 110. In such embodiments, the issuer computer 106 may use a hashing algorithm on the request message to generate a hash value. The issuer computer private key 106b is used with an encryption algorithm to generate the digital signature.

[0115] In some embodiments, the issuer computer 106 may perform the steps of generating and issuing data elements. In some embodiments, the process may occur via an algorithm (e.g., according to a schedule, according to market conditions, according to the value of a relevant fiat currency) or at the request of a user controlling the issuer computer 106.

[0116] In some embodiments, before sending the request message to the payment processor computer 110, the issuer computer 106 may have signed a transaction for a first quantity of data elements for itself and subsequently stored the first quantity of data elements in the issuer mobile wallet 106a. For example, merchant A associated with the issuer computer 106 may have deposited 100,000 points into the issuer mobile wallet 106a.

[0117] The issuer computer 106 may generate data elements in various ways, including but not limited to sending that quantity of data elements to itself as part of a payment transaction message. For example, the issuer computer 106 may generate a first payment transaction message having a source address and a destination address, which may be the address of the issuer computer 106. The first payment transaction message may include a quantity of data elements (e.g., 100,000 points).

[0118] In step 404, the payment processor computer 110 may verify that the issuer possesses the issuer private key 106b and create an entry in the main ledger database 110c representing the transaction that generated the data elements. In such embodiments, the payment processor computer 110 may verify the private key used to sign the request message by using the corresponding public key of the issuer computer 106. In some embodiments, the payment processor computer 110 may verify the digital signature by using the issuer public key to verify the received digital signature, thereby generating a first hash value. Then, the payment processor computer 110 may use the same hashing algorithm that the issuer computer 106 used on the request message to generate a second hash value. When the first hash value and the second hash value match, the digital signature verification is successful.

[0119] When the request message is verified, the payment processor computer 110 will know that the request message was sent by a legitimate issuer of the digital currency system.

[0120] In some embodiments, after receiving a request message from the issuer computer 106, the payment processor computer 110 may determine whether to authorize the issuer computer 106 to generate and issue digital currency. In some embodiments, the payment processor computer 110 may use the identification information associated with the issuer computer 106 to retrieve the profile associated with the issuer computer 106 from the entity profile database 110d. In some embodiments, the payment processor computer 110 may retrieve the second key (e.g., public key) of the key pair from the retrieved profile of the issuer computer 106. The processor and authentication module 110b-1 may determine that the request message is received from an authorized issuer computer 106 by determining whether the request message is digitally signed using the first key, which can be decrypted using the second key associated with the authorized issuer computer 106. In some embodiments, the request message may be encrypted by the issuer private key 106b (e.g., the first key) before being sent by the issuer computer 106. A determination as to whether the request message is digitally signed by a legitimate issuer computer 106 may be made by verifying the request message using the issuer public key (e.g., the second key) stored at the payment processor computer 110, to determine whether the request message is issued by an authorized issuer node.

[0121] In some embodiments, the payment processor computer 110 may also generate a ledger entry 110c-5 indicating the generation and issuance of value token A (as Figure 7 shown). In some embodiments, the generated ledger entry will include a hash that is digitally signed using the issuer private key 106b of the issuer computer 106 and then digitally signed using the private key of the payment processor computer 110. In such an embodiment, this may be an indication that the generated ledger entry is a legitimate entry for a legitimate transaction.

[0122] In some embodiments, once the payment processor computer 110 has generated the ledger entry, the payment processor computer 110 may generate a response message indicating this and send the response message to the issuer computer 106. In some embodiments, the response message may be a sub-ledger update sent by the payment processor computer 110 to the issuer computer 106, as described below.

[0123] Assume that the issuer computer 106 has been authorized to issue digital currency. Then, when the issuer computer 106 receives a response message from the payment processor computer 110 indicating that the issuer computer 106 is authorized to generate and issue digital currency, the issuer computer 106 can then generate digital currency. In some embodiments, the issuer computer 106 can generate and issue digital currency by determining the quantity of digital currency to be created and the currency exchange rate between one digital currency unit and fiat currency (e.g., US dollar, British pound). For example, one digital currency unit can be equivalent to one US dollar.

[0124] In some embodiments, the value token A can be stored in the issuer mobile wallet 106a, representing the quantity of digital currency created by the issuer computer 106. In such embodiments, the ledger entry 110c-5 can include data indicating that the value token A is stored in the issuer mobile wallet 106a.

[0125] In step 406, the payment processor computer 110 can send an update to the issuer sub-ledger 106c, which includes an entry of the main ledger database 110c. In some embodiments, the update to the issuer sub-ledger 106c is based on preferences associated with the issuer computer 106 and / or is sent when the issuer computer 106 requests. In other embodiments, the update to the issuer sub-ledger 106c can be sent as part of a subscription process, where the update is sent at a predetermined time or interval.

[0126] In some embodiments, the update to the issuer sub-ledger 106c can be encrypted by the payment processor computer 110 before being sent to the issuer computer 106. In such embodiments, the update to the issuer sub-ledger 106c can be encrypted using the issuer public key of the issuer computer 106, such that the update to the issuer sub-ledger 106c can only be decrypted using the corresponding issuer private key 106b.

[0127] In step 408, the issuer computer 106 sends a rule message to the payment processor computer 110 to create rules for the previously generated points. In some embodiments, the rule message may be digitally signed using a private key associated with the issuer computer 106 that was previously generated by the payment processor computer 110. In some embodiments, the rule message may also include a first quantity of data elements to be generated. The rule message itself may also be encrypted by the issuer computer 106 before being sent to the payment processor computer 110. The rule message may include one or more rules governing the use of the points previously generated by the issuer computer 106. In some embodiments, the data elements are points having values defined by the rules. In some embodiments, the rules may further specify an exchange rate between the value of the data elements and fiat currency (e.g., 10 points = $1.00).

[0128] In some embodiments, the issuer computer 106 may generate the rule message after generating the points. In other embodiments, the issuer computer 106 may send the rule message to the payment processor computer 110 before generating the points.

[0129] In step 410, the payment processor computer 110 may verify the issuer private key and create an entry in the main ledger database 110c representing the rules applicable to the generated data elements. In such an embodiment, the payment processor computer 110 may verify the private key used to sign the request message by using the corresponding public key of the issuer computer 106. When the request message is verified, the payment processor computer 110 will know that the request message was sent by a legitimate issuer of the digital currency system.

[0130] In some embodiments, the payment processor computer 110 may generate one or more ledger entries 110c-6 and 110c-7 (as Figure 7 shown) that indicate the rules associated with the generated data elements. In some embodiments, the ledger entries 110c-6 and 110c-7 generated based on the rule message may be public entries that can be viewed by both participants and non-participants in the digital currency system. For example, the issuer computer 106 may have a default exchange rate between one unit value of the data element and the US dollar, and that rule will apply to all entities in the system.

[0131] The rules in the ledger entries 110c-6 and 110c-7 may be added to the main ledger database 110c for future transactions that match the criteria associated with the digital currency.

[0132] In some embodiments, the generated ledger entry for a rule will include a hash that is digitally signed using the issuer private key 106b of the issuer computer 106 and then using the private key of the payment processor computer 110. In such an embodiment, this can be an indication that the generated ledger entry is a legitimate entry for a legitimate rule created by the issuer computer 106.

[0133] In step 412, the payment processor computer 110 can send an update to the issuer sub-ledger 106c that includes the rule entries (110c-6 and 110c-7) of the master ledger database 110c. In some embodiments, the update to the issuer sub-ledger 106c can be based on preferences associated with the issuer computer 106 and / or sent when the issuer computer 106 requests it. In some embodiments, the rule entries can be distributed to appropriate sub-ledgers, including one or more public sub-ledgers. The public sub-ledger can contain all publicly available rule entries and can be accessed by non-participants as well as participants in the digital currency system. In some embodiments, the update to the issuer sub-ledger 106c (e.g., the second data entry) can be signed using the private key of the issuer computer 106 before being appended to the issuer sub-ledger 106c.

[0134] In some embodiments, the issuer sub-ledger 106c and the redeemer sub-ledger 108c can include entries from the master ledger database 110c related to rules and / or agreements between the issuer computer 106 and the redeemer computer 108. For example, there can be a rule governing the exchange rate of the digital currency that applies only to the redeemer computer 108, which can be different from the default exchange rate. The ledger entry for this rule will be included in the issuer sub-ledger 106c and the redeemer sub-ledger 108c and can be excluded from the sub-ledgers of other entities in the system. In some embodiments, the ledger entry representing a rule agreed upon by the issuer computer 106 and the redeemer computer 108 can be digitally signed using both the issuer private key 106c and the redeemer private key 108c.

[0135] In some embodiments, the issuer computer 106 may update a rule that has previously been added to the master ledger database 110c. In such an embodiment, the issuer computer 106 may generate an update rule message. The update rule message may be digitally signed using the private key of the issuer computer 106 and may include information related to the modification of the rule. For example, the issuer computer 106 may modify the exchange rate between the value of a data element (e.g., digital currency) and fiat currency from 10 cents = $1.00 to 12 cents = $1.00. In such an embodiment, the issuer computer 106 may send the update rule message to the payment processor computer 110. The payment processor computer 110 may verify the update rule message using the public key associated with the first entity computer and corresponding to the private key. When the update rule message is verified, the payment processor computer 110 may update the master ledger database 110c to include a new rule entry that includes the modification to the rule. The payment processor computer 110 may then transmit the new rule entry to the issuer subledger 106c and any other appropriate subledgers, including one or more public subledgers.

[0136] D. Distribution and Transaction of Digital Currency

[0137] Figure 5 FIG. 500 is a flowchart showing a method of transferring digital currency from an issuer of digital currency to a holder according to an embodiment of the present invention. In some embodiments, in response to a transaction performed by a holder, the issuer may transfer digital currency to issue digital currency to the holder. For example, in the case where the issuer is an airline, the issuer may transfer the digital currency obtained from the mileage completed by using the airline's flights to the holder. In another example, the issuer may transfer digital currency for a transaction performed by the holder using a linked financial account.

[0138] In step 502, the issuer computer 106 may send a transaction message to the Holder A computing device 102 to transfer data elements (e.g., points) within the digital currency system from the issuer mobile wallet 106a to the Holder A mobile wallet 102a. In some embodiments, the issuer computer 106 may generate a transaction message where the source address is the address of the issuer computer 106 and the destination address is the address of the Holder A computing device 102. In some embodiments, the issuer computer 106 may request the address of the Holder A computing device 102 from the payment processor computer 110. In such an embodiment, the payment processor computer 110 may store the address of the Holder A computing device 102 from the entity profile database 110d. In such an embodiment, the entity profile database 110d may act as an entity directory within the system 100. In some embodiments, the issuer computer 106 may store the address of the Holder A computing device 102 for future transactions.

[0139] After generating the data elements (see Figure 4 ), the issuer computer 106 may create a transaction to transfer a certain number of data elements to one of the holders (e.g., the Holder A computing device 102). For example, assume the issuer computer 106 pre-generates 100,000 units of digital currency. The issuer computer 106 may then want to transfer 500 units of digital currency to the Holder A computing device 102. To distribute 500 units of digital currency to the Holder A computing device 102, the issuer computer 106 may generate a second transaction message that includes the address of the issuer computer 106, the address of the Holder A computing device 102, and the quantity of digital currency (e.g., 500 units). The transaction message may be encrypted by the issuer computer 106 using the public key associated with the Holder A computing device 102. This allows the transaction message to be decrypted by the Holder A private key 102b. The transaction message may also be digitally signed using the private key of the issuer computer 106. This allows the transaction message to be verified using the public key of the issuer computer 106 to determine that the transaction is valid and originated from the genuine issuer computer 106. The transaction message may then be sent to the Holder A computing device 102.

[0140] In step 504, the Holder A computing device 102 and the Issuer computer 106 may update their respective mobile wallets (102a and 106a). In some embodiments, the Holder A mobile wallet 102a may be updated to include 500 digital currency units from the Issuer computer 106, and the Issuer mobile wallet 106a may be updated to reduce the digital currency by 500 units. In some embodiments, updating the Holder A mobile wallet 102a may also include transferring a value token (e.g., value token A) from the Issuer mobile wallet 106a to the Holder A mobile wallet 102a.

[0141] In step 506, the Payment Processor computer 110 may receive a transaction message that includes details of the transfer or distribution of a data element (e.g., points) from the Issuer computer 106 to the Holder A computing device. The transaction message may be received by the Payment Processor computer 110 via the communication network 112. In some embodiments, the Payment Processor computer 110 may receive the transaction message after the Holder A mobile wallet 102a and the Issuer mobile wallet 106a have been updated. In other embodiments, the Payment Processor computer 110 may receive the transaction message before the Holder A mobile wallet 102a and the Issuer mobile wallet 106a are updated.

[0142] In step 508, the Payment Processor computer 110 may verify the transaction received in the transaction message. In such an embodiment, the Payment Processor computer 110 may verify the private key of the Issuer computer 106 used to sign the transaction message by using the corresponding public key of the Issuer computer 106. When the request message is verified, the Payment Processor computer 110 will know that the request message was sent by a legitimate issuer of the digital currency system.

[0143] In step 510, the Payment Processor computer 110 may create a ledger entry in the Main Ledger database 110c for the transaction received in the transaction message. In some embodiments, the Payment Processor computer 110 may generate a ledger entry 110c-8 (as Figure 7 shown) demonstrating the transfer of value token A from the Issuer computer 106 mobile wallet 106a to the Holder A computing device 102 mobile wallet 102a. In some embodiments, the private keys of the Issuer computer 106 and the Holder A computing device 102, which are parties to the transaction, and the private key of the Payment Processor computer 110 may be used to digitally sign the ledger entry to indicate that the transaction has been verified and the entry is legitimate.

[0144] In step 512, the payment processor computer 110 may initiate the process of updating the appropriate sub-ledger. In some embodiments, the payment processor computer 110 may send updates to the issuer sub-ledger 106c and the Holder A sub-ledger 106a because the associated computers participated in the transaction. In some embodiments, the issuer sub-ledger 106c may also be updated along with the transaction. In some embodiments, the payment processor computer 110 may send a ledger entry (110c-8 in the master ledger database 110c) that indicates a transfer of value token A from the issuer computer 106 mobile wallet 106a to the Holder A computing device 102 mobile wallet 102a.

[0145] The Holder A sub-ledger 102c may include a subset of the entries in the master ledger database 110c. For example, in some embodiments, once the transaction of distributing the digital currency from the issuer computer 106 to the Holder A computing device 102 is complete, the Holder A sub-ledger 102c may be updated to include the ledger entry (e.g., 110c-8) that attests to the transaction. The Holder A sub-ledger 102c may include only the ledger entries related to the transactions involving the Holder A computing device 102 and the rules for managing the digital currency. For example, this may include rules that specify any details about the digital currency (e.g., expiration date, transaction value with one or more redeemers).

[0146] E. Redemption of Digital Currency

[0147] Figure 6 FIG. 600 is a flow chart showing a method for a redeemer to redeem digital currency from an issuer of the digital currency according to an embodiment of the present invention.

[0148] As part of the transaction process between the holder and the redeemer, the redeemer computer 108 may want to redeem the digital currency it received from the holder (e.g., the Holder A computing device 102). For example, Holder A may have purchased an item from the redeemer with 400 data elements of digital currency. The Holder A computing device 102 may interact with the redeemer computer 108 to transfer the 400 data elements.

[0149] In some embodiments, the process of transferring data elements between the holder (e.g., Holder A) and the redemption partner may be performed in a manner similar to that described for transferring data elements from the issuer computer 110 to the Holder A computing device 102. In such an embodiment, the Holder A computing device 102 may transmit a transaction message to the redeemer computer 108 to transfer data elements (e.g., points) within the digital currency system from the Holder A mobile wallet 102a to the redeemer mobile wallet 108a.

[0150] As part of a transaction between the Holder A computing device 102 and the Redeemer computer 108, a value token B can be generated. In some embodiments, the Payment Processor computer 110 can also generate a ledger entry 110c-9 indicating the generation and issuance of the value token B (as Figure 7 shown). In some embodiments, the value token B can be stored in the Holder A mobile wallet 102a, and the ledger entry 110c-9 can include data indicating that the value token B is stored in the Holder A mobile wallet 102a. The master ledger database 110c can also include ledger entries for transactions between the Holder A computing device 102 and the Redeemer computer 108 (e.g., 110c-10), as well as ledger entries for transferring the value token B from the Holder A mobile wallet 102a to the Redeemer computer 108's mobile wallet 108a (e.g., 110c-11).

[0151] In step 602, the Redeemer computer 108 initiates a redemption transaction to redeem a data element (e.g., points) from the Issuer computer 106. In some embodiments, the data element can be stored as a value token in the mobile wallet 108a associated with the Redeemer computer 108. The value token can be transferred from one mobile wallet to another.

[0152] In some embodiments, the Redeemer computer 108 can send a redemption transaction message to the Issuer computer 106 to transfer a data element within the digital currency system from the Redeemer mobile wallet 108a to the Issuer mobile wallet 108a. In some embodiments, the Redeemer computer 108 can generate a redemption transaction message where the source address is the address of the Redeemer computer 108 and the destination address is the address of the Issuer computer 106.

[0153] In step 604, the Redeemer computer 108 and the Issuer computer 106 can update their respective mobile wallets (108a and 106a). In some embodiments, the Redeemer mobile wallet 108a can be updated to reduce the digital currency of 400 data elements redeemed to the Issuer computer 106, and the Issuer mobile wallet 106a can be updated to increase the digital currency by 400 data elements. In some embodiments, updating the Redeemer mobile wallet 108a can also include transferring a value token (e.g., value token B) from the Redeemer mobile wallet 108a to the Issuer mobile wallet 106a.

[0154] In step 606, the payment processor computer 110 may receive a redemption transaction message that includes details of the transfer or distribution of data elements (e.g., points) from the redeemer computer 108 to the issuer computer 106. The redemption transaction message may be received by the payment processor computer 110 via the communication network 112.

[0155] In step 608, the payment processor computer 110 may verify the redemption transaction received in the redemption transaction message. In such an implementation, the payment processor computer 110 may verify the private key of the redeemer computer 108 used to sign the redemption transaction message by using the corresponding public key of the redeemer computer 108. When the request message is verified, the payment processor computer 110 will know that the request message was sent by a legitimate redeemer of the digital currency system.

[0156] In some implementations, the payment processor computer 110 may retrieve a second data entry (e.g., Figure 7 110c-6 in) from the main ledger database 110c that indicates one or more rules associated with redeeming a certain number of data elements. In some implementations, the data elements may be points with values defined by the rules. In some implementations, the second data entry may include one or more rules that may indicate an exchange rate between the value of the data elements and fiat currency. For example, the rule may indicate that, by agreement between the redeemer computer 108 and the issuer computer 106, the issuer computer will redeem each 10 points owned by the redeemer computer 108 for $1.00. Additionally, other rules stored in the main ledger database 110c may limit the amount that the redeemer computer 108 may redeem to the issuer computer 108.

[0157] In step 610, the payment processor computer 110 may create a ledger entry in the main ledger database 110c for the transaction received in the redemption transaction message. In some implementations, the payment processor computer 110 may generate a ledger entry 110c-12 (as Figure 7 shown) that certifies the transfer of value token A from the redeemer computer 108 mobile wallet 108a to the holder A computing device 106 mobile wallet 106a.

[0158] In step 612, the payment processor computer 110 may send updates to the issuer sub-ledger 106c and the holder A sub-ledger 108a because the associated computers participated in the transaction. In some implementations, the payment processor computer 110 may send a ledger entry (110c-12 in the main ledger database 110c) that indicates the transfer of value token B from the holder A computer 102 mobile wallet 102a to the issuer computing device 106 mobile wallet 106a.

[0159] Subsequently, a settlement process can be initiated between the issuer computer 106 and the redeemer computer 108. The settlement process can be based on the quantity of digital currency redeemed by the redeemer computer 108 and one or more rules regarding the digital currency. In such an implementation, one or more rules can include rules defining the conversion of data elements to fiat currency (e.g., US dollars, British pounds).

[0160] For example, the payment processor computer 110 can retrieve the financial account information (e.g., account number) of the issuer associated with the issuer computer 106 and the redeemer associated with the redeemer computer 108. In some implementations, the payment processor computer 110 can retrieve the financial account information from the issuer computer 106 and the redeemer computer 108. In other implementations, the payment processor computer 110 can initiate the settlement process by accessing a profile database to locate the profiles associated with the issuer computer 106 and the redeemer computer 108 and retrieving the financial information of the issuer and the redeemer 108 that may have been received as part of a registration process.

[0161] In other implementations, the settlement process can be performed by the issuer sending a payment to the redeemer by an alternative means (e.g., check payment).

[0162] III. Additional Implementations

[0163] In some implementations, the payment processor computer 110 can be one of a plurality of payment processor computers. In an implementation where there is more than one payment processor computer, each payment processor computer can include a master ledger database. When the payment processor computer receives a request message, one or all of the payment processor computers can create an entry in the master ledger database attesting to the transaction. In such an implementation, each payment processor computer among the plurality of payment processor computers can temporarily add a ledger entry and can perform a reconciliation process to synchronize the respective master ledger databases to ensure that all master ledger databases include the same items. In such an implementation, the payment processor computer can refrain from verifying the ledger entry (by digitally signing the ledger entry using the private key of the plurality of payment processor computers) until there is an agreement among the plurality of payment processor computers as to what the next ledger entry should be. As will be understood by those of ordinary skill in the art, the methods of reconciliation and synchronization between the various master classification databases can be performed in any suitable manner using one or more algorithms or processes.

[0164] In some embodiments, the rule messages can be sent and stored outside the system. In such embodiments, the rules may not be placed in the main ledger database 110c. Instead, when a transaction or redemption process is executed, the rules can be stored outside the system 100 and accessed by entities within the system 100. Additionally, in some embodiments where there are no rules defined by the issuer computer 106, default rules stored outside the system can be accessed and applied to the transaction.

[0165] In other embodiments, in the case where the issuer computer 106 provides digital currency to an issuing partner, the transfer of the digital currency to the issuing partner computer 114 can be performed as described above with reference to Figure 5 that which has been described. In such embodiments, any ledger entry that manages the rules for the distribution of digital currency by the issuing partner computer 114 can be digitally signed using the issuer computer private key 106b and the issuing partner private key 114b. In some embodiments, the ledger entry can also be digitally signed using the redeemer private key 108b.

[0166] In some embodiments, the issuer computer 106 can generate digital currency in the form of a coupon value, which can be valid and used concurrently with data elements (e.g., points) of the digital currency system. In such embodiments, the generated coupon value can carry an expiration date indicating that it is valid within a predetermined time period. In some embodiments, the coupon can be an agreement between the issuer computer and the redeemer computer, which states that the issuer will repurchase the previously issued data elements at a specific exchange rate. In such embodiments, the coupon can be used as a put option, which is an option to sell an asset at a specified price on or before a specific date. For example, if returned before December 31, 2016, issuer A may offer to repurchase the previously issued data elements at a rate of 1 US dollar for every 3 points.

[0167] IV. Technical Advantages

[0168] Embodiments of the present invention provide numerous advantages and technical benefits.

[0169] For example, the decentralization of the system enables each entity within the system to have the data required for transactions in its unique sub-ledger, which significantly reduces the time and computing resources required to execute transactions. Transactions can be conducted between the entities involved in the transaction, and once the transaction is completed, the details of the transaction are sent to a central computer for verification and stored in the main ledger. This eliminates the need to send authorization request messages during the transaction itself and the friction caused by the authentication and authorization processes performed during typical transactions.

[0170] Accordingly, embodiments of the present invention eliminate the need for extensive infrastructure required by current solutions. Since messages sent between trading parties can be used to handle the generation, distribution, and redemption of points, and are implemented using a single master ledger and multiple sub-ledgers, a single system can be used to manage multiple different programs, with the rules for each program embodied in the rule entries in the ledger.

[0171] In addition, unlike typical cryptocurrency systems (such as Bitcoin) that require multiple parties to maintain a complete blockchain (such as a ledger) of transactions performed since the system was launched, embodiments of the claimed invention provide the option to allow entities within a digital currency system to maintain a subset of the entries stored in the master ledger. The subset of entries may include only those entries relevant to the entity, such as the transactions performed by the entity and the rules governing the digital currency held by the entity.

[0172] Furthermore, in embodiments of the present invention, each entity (e.g., issuer, holder, redeemer) must be authenticated and approved by a payment processing computer to ensure that only specific entities have the right to generate digital currency and conduct transactions using digital currency. Combined with the ability to link digital currency to fiat currency, this can provide enhanced security to ensure the validity of digital currency and prevent and reduce the risk of fraud involving digital currency.

[0173] V. Example Computer Systems

[0174] The various participants and elements described herein can operate one or more computer devices to facilitate the functions described herein. Any element in the figures, including any server or database, can use any suitable number of subsystems to facilitate the functions described herein.

[0175] Examples of such subsystems or components are shown in Figure 8 In. Figure 8 Any subsystem or component shown in can be included in any of the devices, apparatuses, or systems described previously. Figure 8The subsystems shown in the figure are interconnected via system bus 800. Additional subsystems are shown, such as printer 808, keyboard 816, fixed disk 818 (or other memory including computer-readable media), monitor 812 coupled to display adapter 810, and other devices. Peripherals and input / output (I / O) devices coupled to I / O controller 802 (which may be a processor or any suitable controller) can be connected to the computer system by any means known in the art, such as serial port 814. For example, serial port 814 or external interface 820 can be used to connect the computer device to a wide area network, such as the Internet, a mouse input device, or a scanner. The interconnection via the system bus allows the central processor 806 to communicate with each subsystem and control the execution of instructions from system memory 804 or fixed disk 818 and the exchange of information between the subsystems. System memory 804 and / or fixed disk 818 can be embodied as computer-readable media.

[0176] Specific details regarding some of the above aspects are provided above. Without departing from the spirit and scope of the embodiments of the present technology, the specific details of the specific aspects can be combined in any suitable manner. For example, in some embodiments of the present technology, back-end processing, data analysis, data collection, and other transactions can all be combined. However, other embodiments of the present technology can relate to specific embodiments related to each individual aspect, or specific combinations of these individual aspects.

[0177] It should be understood that the present technology as described above can be implemented in the form of control logic using computer software (stored in a tangible physical medium) in a modular or integrated manner. Although the present invention has been described using a specific combination of hardware and software in the form of control logic and programming code and instructions, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. Based on the disclosure and teachings provided herein, those of ordinary skill in the art will know and understand other ways and / or methods of implementing the present technology using hardware and combinations of hardware and software.

[0178] Any software component or function described in this application can be implemented as software code executed by a processor using, for example, conventional or object-oriented techniques and using any suitable computer language, such as, for example, Java, C++, or Perl. The software code can be stored as a series of instructions or commands on a computer-readable medium, such as random access memory (RAM), read-only memory (ROM), magnetic media (such as a hard disk or floppy disk), or optical media (such as a CD-ROM). Any such computer-readable medium can reside on or inside a single computing device and can exist on or inside different computing devices within a system or network.

[0179] The above description is illustrative and not restrictive. Many variations of the technology will be apparent to those skilled in the art after reading this disclosure. Accordingly, the scope of the technology should be determined not with reference to the above description, but instead should be determined with reference to the appended claims, along with their full scope of equivalents.

[0180] In some embodiments, any entity described herein may be implemented by a computer that performs any or all of the functions and steps disclosed.

[0181] Without departing from the scope of the technology, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0182] Unless clearly indicated to the contrary, the recitation of "a," "an," or "the" is intended to mean "one or more."

[0183] All patents, patent applications, publications, and descriptions mentioned above are hereby incorporated by reference in their entirety for all purposes. They are not admitted to be prior art.

Claims

1. A method for managing data elements using a distributed ledger, the method comprising: sending, by a distributor computer, a request message for generating data elements to a processor computer, the request message being digitally signed using a first key associated with the distributor computer and including a first quantity of the data elements to be generated; receiving, by the distributor computer, from the processor computer a response message indicating a first update to a distributor sub-ledger, the first update including a first data entry, the first data entry including the first quantity of the data elements, wherein the first data entry is generated by the processor computer after verifying the request message using a second key associated with the distributor computer to determine that the distributor computer is authorized to generate the data elements; sending, by the distributor computer, a rule message to the processor computer, the rule message being digitally signed using the first key associated with the distributor computer and including rules governing the use of the data elements; and receiving, by the distributor computer, from the processor computer a response message indicating a second update to the distributor sub-ledger, the second update including a second data entry for the rules, wherein the second data entry is generated by the processor computer after verifying the rule message using the second key associated with the distributor computer.

2. The method according to claim 1, the method further comprising: sending, by the distributor computer, a transaction message for transferring a second quantity of the data elements from the distributor computer to a holder computer to the processor computer, the transaction message being digitally signed using the first key associated with the distributor computer and including the second quantity of the data elements to be transferred; updating, by the distributor computer, a first storage application associated with the distributor computer to indicate the transfer of the second quantity of the data elements; and receiving, by the distributor computer, from the processor computer a response message indicating a third update to the distributor sub-ledger, the third update including a third data entry, the third data entry including the second quantity of the data elements transferred to the holder computer, wherein the third data entry is generated by the processor computer after verifying the transaction message using the second key associated with the distributor computer.

3. The method according to claim 2, wherein the third update is also made to a main ledger and a holder sub-ledger including a subset of the first entries of the main ledger.

4. The method according to claim 2, further comprising signing, by the distributor computer, the third data entry using the first key of the distributor computer before updating the distributor sub-ledger with the third data entry.

5. The method according to claim 1 further comprises signing, by the distributor computer using the first key of the distributor computer, the second data entry before the second data entry is appended to the distributor sub-ledger.

6. The method according to claim 1, wherein the distributor sub-ledger is a read-only copy of the master ledger.

7. The method according to claim 1, wherein the first key is a private key and the second key is a public key associated with the private key.

8. The method according to claim 1 further comprises: sending, by the distributor computer, an update rule message to the processor computer, the update rule message being digitally signed using the first key associated with the distributor computer and including a modification to the rule; and receiving, by the distributor computer, a response message from the processor computer, the response message indicating a third update to the distributor sub-ledger, the third update including a third data entry that includes the modification to the rule, wherein the processor computer uses the second key associated with the distributor computer to verify the update rule message.

9. The method according to claim 1 further comprises: encrypting, by the distributor computer, the request message before sending the request message.

10. A distributor computer comprising: a data processor; and a computer-readable medium coupled to the data processor, the computer-readable medium including code executable by the data processor to implement the method according to any one of claims 1 to 9.

11. A method for managing data elements using a distributed ledger, the method comprising: sending, by a redeemer computer, a request message to a processor computer to redeem a certain amount of data elements through a distributor computer, the request message being digitally signed using a first key associated with the redeemer computer and including the amount of the data elements to be redeemed; sending, by the redeemer computer, a redemption transaction message to the distributor computer to effect the redemption of the amount of the data elements; receiving, by the redeemer computer, from the processor computer an indication of an update to the master ledger to include a data entry indicating the redemption of the amount of the data elements through the distributor computer; updating, by the redeemer computer, a first storage application associated with the redeemer computer to indicate the redemption of the amount of the data elements; wherein the request message is verified by the processor computer using a second key associated with the redeemer computer; and performing, by the redeemer computer, a settlement process through the distributor computer.

12. The method according to claim 11 further comprises: receiving, by the redeemer computer, from the processor computer a response message indicating an update to the redeemer sub-ledger, the update including the data entry.

13. The method according to claim 11, wherein the data element is received by a redeemer operating the redeemer computer as part of a transaction with a holder operating the holder computer.

14. The method according to claim 11, wherein the first key is a private key and wherein the second key is a public key associated with the private key.

15. A redeemer computer, comprising: a data processor; and a computer-readable medium coupled to the data processor, the computer-readable medium including code executable by the data processor to implement the method according to any one of claims 11 to 14.

Images