EP3387603A1 - Methods and systems of using a cryptocurrency system to manage payments and payment alternatives - Google Patents
Methods and systems of using a cryptocurrency system to manage payments and payment alternativesInfo
- Publication number
- EP3387603A1 EP3387603A1 EP16873533.0A EP16873533A EP3387603A1 EP 3387603 A1 EP3387603 A1 EP 3387603A1 EP 16873533 A EP16873533 A EP 16873533A EP 3387603 A1 EP3387603 A1 EP 3387603A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- computer
- ledger
- issuer
- distributor
- holder
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3825—Use of electronic signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/387—Payment using discounts or coupons
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
- G06Q30/0226—Incentive systems for frequent usage, e.g. frequent flyer miles programs or point systems
Definitions
- Incentive programs and loyalty programs are developed and managed by companies and financial institutions as a means to engender consumer loyalty.
- Incentives can be provided to consumers through the accumulation of points from conducting transactions. For example, the consumer can exchange points for various goods and services offered by the issuer of the loyalty points. As the number of payment alternatives increases, there is an issue that arises with as to how to manage these payment alternatives in an efficient manner.
- Embodiments of the present invention address these and other problems, individually and collectively.
- Embodiments of the present invention relate to systems and methods for the efficient management of a digital currency system using a cryptocurrency scheme.
- Embodiments utilize a payment processor computer to manage entities in the digital currency system, which have the rights to generate, distribute, transact with, and redeem units of a digital currency.
- the digital currency may represent points in a loyalty program operated by an entity or organization.
- Transactions performed using the digital currency and rules governing 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.
- One embodiment of the invention is directed to a method comprising, receiving, by a processor computer from a distributor computer, a request message for generating data elements.
- the request message may be digitally signed using a first key associated with the distributor computer and include a first amount of the data elements to be generated.
- the method further comprises validating 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.
- the method further comprises generating a first data entry in a master ledger including the first amount of the data elements, and transmitting a first update to a distributor sub-ledger of the distributor computer, the first update including the first data entry.
- the method further comprises receiving, from the distributor computer, a rules message digitally signed using the first key associated with the distributor computer and including a rule governing the use of the data elements.
- the method further comprises validating the rules message using the second key associated with the distributor computer.
- the method further comprises updating, the master ledger to include a second data entry for the rule, and transmitting a second update to the distributor sub-ledger, the second update including the second data entry.
- Another embodiment of invention is directed 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 comprising receiving, by a processor computer from a distributor computer, a request message for generating data elements.
- the request message may be digitally signed using a first key associated with the distributor computer and include a first amount of the data elements to be generated.
- the method further comprises validating 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.
- the method further comprises generating a first data entry in a master ledger including the first amount of the data elements, and transmitting a first update to a distributor sub-ledger of the distributor computer, the first update including the first data entry.
- the method further comprises receiving, from the distributor computer, a rules message digitally signed using the first key associated with the distributor computer and including a rule governing the use of the data elements.
- the method further comprises validating the rules message using the second key associated with the distributor computer.
- the method further comprises updating, the master ledger to include a second data entry for the rule, and transmitting a second update to the distributor sub- ledger, the second update including the second data entry.
- Another embodiment of invention is directed to a method comprising receiving, from a redeemer computer, a request message to perform a redemption of an amount of data elements with a distributor computer.
- the request message may be digitally signed using a first key associated with the redeemer computer and including an amount of the data elements to be redeemed.
- the method further comprises validating the request message using a second key associated with the redeemer computer.
- the method further comprise updating a master ledger to include a data entry, the data entry indicating the redemption of an amount of data elements with the distributor computer, and initiating a settlement process using information for the redeemer computer stored in a profiles database.
- Another embodiment of invention is directed 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 comprising receiving, from a redeemer computer, a request message to perform a redemption of an amount of data elements with a distributor computer.
- the request message may be digitally signed using a first key associated with the redeemer computer and including an amount of the data elements to be redeemed.
- the method further comprises validating the request message using a second key associated with the redeemer computer.
- the method further comprise updating a master ledger to include a data entry, the data entry indicating the
- FIG. 1 shows a block diagram of an exemplary system for generating and managing a digital currency system according to an embodiment of the present invention.
- FIG. 2 shows a detailed block diagram for a payment processor computer according to an embodiment of the present invention.
- FIG. 3 shows a flow diagram of a method of enrollment and key
- FIG. 4 shows a flow diagram of a method of generating digital currency by an issuer according to an embodiment of the present invention.
- FIG. 5 shows a flow diagram of a method of transferring digital currency between entities according to an embodiment of the present invention.
- FIG. 6 shows a flow diagram of a method of a redeemer redeeming digital currency with an issuer of the digital currency according to an embodiment of the present invention.
- FIG. 7 shows an exemplary master ledger database according to an embodiment of the present invention.
- FIG. 8 shows an exemplary block diagram of a computer apparatus according to an embodiment of the present invention.
- Digital currency may include units of value that may be used as a form of payment for transactions, including financial transactions.
- Digital currency may be currency that is electronically generated by and stored within a user computing device.
- Digital currency may be represented by data elements (e.g., points, dollars, etc.) having a defined value or conversion rate, and may or may not be a fiat currency. In some embodiments, the defined value and the conversion rate can be modified at any time by the issuer of the digital currency. If the digital currency is a non-fiat currency such as loyalty points, it may also be purchased using conventional forms of currency (e.g., fiat currency) and generated with a specific value. Typically, the digital currency may not have a physical form of tender but may be accessible through a user computing device (e.g., mobile device) using a software application such as a digital wallet or mobile application.
- a software application such as a digital wallet or mobile application.
- Data elements may include a unit of data.
- data elements may be the units of data for a digital currency system.
- the data elements may represent points within the digital currency system, where the number of data elements represents the number of points.
- data elements may also be referred to as units, credits, or points.
- a "master ledger” may include a compilation of data from previous transactions.
- the master ledger may be stored in a database and/or in a particular file structure.
- the master ledger may store data from any suitable number (e.g., all) of previous transactions performed using a digital currency.
- An entry in the master ledger may include the date and time of a transaction, the transaction amount, and the participants to the transaction (e.g., the sender and the receiver of the transaction amount).
- the master ledger may be embodied by a block chain, where each new block in the block chain is algorithmically determined based on new transactions and previous blocks in the block chain.
- the master ledger may be stored and managed by a central processing computer (e.g., a payment processor computer).
- a "sub-ledger” may include a sub-set of data in a master ledger.
- the sub- ledger may be stored in a database and/or in a particular file structure.
- the sub-ledger may store data from a sub-set of data from previous transactions performed using a digital currency. Such data may include the date and time of a transaction, the transaction amount for the transaction, and the participants of the transaction (e.g., the sender and the receiver of the transaction amount).
- the sub- ledger may be embodied by a block chain, where each new block in the block chain is algorithmically determined based on new transactions and previous blocks in the block chain.
- the sub-ledger may be stored and managed by a central processing computer (e.g., a payment processor computer) in a digital currency system.
- a central processing computer e.g., a payment processor computer
- other entities within the digital currency system may store sub- ledgers of the master ledger.
- Each sub-ledger may include entries from the master ledger that are relevant to the particular entity or node associated with that entity.
- only particular entities may see the contents of a sub-ledger.
- a sub-ledger entry for a transaction may only be seen by the participants to the transaction and the payment processor computer that processed the transaction.
- one or more nodes may store a read-only copy of the master ledger, such that the master ledger is unalterable by those particular nodes or entities.
- a "data entry” may include an entry having information.
- a data entry may be a recordation of information.
- each data entry may include pieces of information evidencing a different event (e.g., a transaction, a rule creation).
- the data entry may include information regarding a completed transaction, including a sender address, a recipient address, a transaction amount, etc.
- a "digital signature” may include a mathematical technique used to validate the authenticity and integrity of a message.
- a digital signature may be a unique value generated from the message and a private key using an encryption algorithm.
- a public key associated with the private key may be used to verify the signature (as is known in the art).
- a digital signature may be a numeric value, an alphanumeric value, or any other type of data including a graphical representation.
- a "key” may include a piece of information that determines a functional output of a cryptographic algorithm or cipher.
- a hash function may include a function that can map data of an arbitrary size to data of a fixed size.
- a "nonce” may include a random or pseudo-random value.
- the nonce may be an arbitrary number that may be used only once.
- a nonce may be used in cryptography as part of generating a hash function.
- a nonce may be a 32-bit field. However, in other embodiments, the nonce may be smaller or larger than 32-bits.
- a "message” may include an electronic message that may communicate information.
- An electronic message may be in any suitable form including an e-mail, a short messaging service (SMS) message, a multimedia messaging service (MMS) message, a hypertext transfer protocol (HTTP) request message, an ISO 8583 message, a transmission control protocol (TCP) packet, a web form submission.
- the message may be directed to any suitable location, such as an e-mail address, a telephone number, an internet protocol (IP) address, or a uniform resource locator (URL).
- a message may comprise a mix of different message types, such as both email and SMS messages.
- a "profile” may refer to information regarding an entity.
- the profile may be a representation of information regarding the entity, including rights and restrictions, identification data, and verification data.
- a profile for an entity may include data indicating the type of role the entity has within a digital currency system.
- the profile may also be used to store financial information for a user.
- the profile may be stored in a database and be linked to an identifier associated with the entity the profile is related to.
- An entity may have one or more profiles.
- a "value token” may be an identifier representing a value.
- a value token may have value associated with it that allows it to be transferred from one entity to another entity.
- a value token may be transferred from a first entity to a second entity as part of a transaction, such as a points disbursement, transfer in exchange for another value, and a redemption for fiat currency.
- a "payment processor computer” may include a server computer used for payment processing.
- a payment processor computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.
- the payment processor computer may operate multiple server computers.
- each server computer may be configured to process transaction for a given region or handle transactions of a specific type based on transaction data.
- each server computer may be configured to store a copy of a master ledger of transactions.
- a payment processing server computer may be present in a payment processing network.
- a payment processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services.
- An exemplary payment processing network may include VisaNetTM. Networks that include VisaNetTM are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNetTM, in particular, includes an integrated payments system (Integrated Payments system) which processes authorization requests and a Base II system, which performs clearing and settlement services.
- the payment processing network may use any suitable wired or wireless network, including the Internet.
- “Initiating” may include taking steps to start a process or performing at least initial steps in the process itself.
- initiating, by the processor computer, a settlement process using financial information for the redeemer computer stored in a profiles database can refer to the actual process required to complete the action relating to the settlement process.
- initiating, by the processor computer, a settlement process using financial information for the redeemer computer stored in a profiles database can also include sending a message with instructions for performing a settlement process.
- a "server computer” may include a powerful computer or cluster of computers.
- the server computer can be a large mainframe, a
- the server computer may be a database server coupled to a Web server.
- the server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers.
- the server computer may comprise one or more computational
- apparatuses may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.
- Embodiments of the present invention may be directed to implementing a digital currency system using cryptocurrency payment network techniques.
- a payment processor computer may manage the rights and restrictions granted to entities within the digital currency system.
- Some nodes in the cryptocurrency payment network may be issuers that are granted the right to issue and generate digital currency, while other nodes may be holders or redeemers that are granted the right to distribute and transact using the digital currency.
- the redeemer nodes may use the rules governing the digital currency for redemptions of digital currency for a fiat currency.
- FIG. 1 shows a block diagram of an exemplary system 100 for generating and managing a digital currency system according to an embodiment of the present invention.
- the system 100 in FIG. 1 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 1 10.
- the systems and computers are shown to interact via one or more communications networks 1 12 (e.g., one or more of the Internet, private communication networks, and public communication networks).
- Each of these systems and computers may be in operative communication with each other via any suitable communication medium (including the Internet), using any suitable communications protocol.
- an optional issuing partner computer 114 coupled to the issuer computer 106 may also interact with the systems and computers shown in FIG. 1 via the one or more communications networks 1 12.
- FIG. 1 For simplicity of illustration, a certain number of components are shown in FIG. 1 . It is understood, however, that embodiments of the invention may include more than one of each component. In addition, some embodiments of the invention may include fewer than or greater than all of the components shown in FIG. 1. Thus, in FIG. 1 , the inclusion of dotted lines indicates optional features that serve as a reminder that the number of these entities included in various embodiments is flexible.
- the holder A and holder B computing devices 102 and 104 may be in any suitable form.
- suitable computing devices may be hand-held and compact so that they can fit into a user's pocket.
- Examples of computing devices 102 and 104 may include any device capable of accessing the Internet or other suitable network.
- Specific examples of computing devices 102 and 104 include cellular or wireless phones (e.g., smartphones), tablet phones, tablet computers, laptop computers, desktop computers, terminal computers, work stations, personal digital assistants (PDAs), physical cryptocurrency wallet hardware, pagers, portable computers, smart cards, wearable devices such as smartwatches, vehicles such as automobiles with remote communication capabilities, and the like.
- a computing device and a corresponding payment device associated with the holder may be embodied by a single device (e.g., a mobile phone that can be used to conduct a payment transactions).
- the computing devices 102 and 104 may each include a processor and a computer readable medium coupled to the processor.
- the computer readable medium may comprise code, executable by the processor for performing the functionality described herein.
- the computing devices 102 and 104 may transmit data through the communications network 1 12 to the issuer computer 106, the redeemer computer 108, the payment processor computer 1 10, and to each other.
- each of the 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 encryption key), and a sub-ledger (102c and 104c).
- a mobile wallet 102a and 104a
- mobile wallet software such as a mobile wallet application
- a private key 102b and 104b
- a sub-ledger 102c and 104c
- 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.
- the mobile wallet may store data indicating the digital currency acquired 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 the digital currency acquired from the issuer computer 106 (or another entity within the system 100).
- the mobile wallet (102a and 104a) can store user profile information, payment information, bank account information, and/or the like.
- the mobile wallet 102a and 104a can be used in a variety of transactions, such as but not limited to electronic commerce, money transfer/personal payments, mobile commerce, proximity payments, and/or the like for retail purchases, digital goods purchases, and transferring funds between users.
- the holder A private key 102b associated with the holder A computing device 102 may be obtained from the payment processor computer 1 10 as part of an enrollment process in the system 100.
- the holder A private key 102b may be a numeric 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 a corresponding holder A public key.
- 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 validate the digital signature associated with the message.
- the message By encrypting the message with holder A private key 102b, the message may be considered to be digitally signed. It can be guaranteed that only an entity or person in possession of holder A private key 102b could have encrypted the message, thereby verifying the encryptor and sender of the message as holder A when the message is decrypted using holder A public key.
- a key generation module 1 10b-2 in the payment processor computer 1 10 may generate a public and private key pair for the holder A computing device 102.
- a similar operation may be performed upon receiving a request from the holder B computing device 104.
- the holder A sub-ledger 102c associated with the holder A computing device 102 may contain a sub-set of the ledger entries contained in the master ledger database 1 10c stored at the payment processor computer 1 10.
- the sub-set of the ledgers entries contained in the holder A sub-ledger 102c may be those ledgers entries relevant to transactions involving the holder A computing device 102, the digital currency stored in the holder A mobile wallet 102a, as well as any associated rules governing the digital currency stored in the holder A mobile wallet 102a.
- the holder A sub-ledger 102c may not include transactions that the holder A computing device 102 was not involved in.
- the sub-set of the ledger entries in the holder A sub-ledger 102c may be read-only entries that cannot be altered by the user associated with the holder A computing device 102.
- the holder B computing device 104 may include a holder B mobile wallet 104a to store and maintain the digital currency, a holder B private key 104b for encrypting messages, and a holder B sub-ledger 104c for storing records of
- each of the issuer computer 106 and the redeemer computer 108 may be a computer associated with a separate entity.
- 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 comprising code, executable by the processor for performing the functionality described herein.
- the system 100 may include the issuer computer 106 and the redeemer computer 108 in communication via the communications network 1 12.
- each of the issuer computer 106 and the redeemer computer 108 may be granted the rights and ability to participate in the system 100 by the payment processor computer 1 10.
- the issuer computer 106 may include a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor for performing the functionality described herein.
- the issuer computer 106 may be an entity that is capable of generating and distributing digital currency. In some embodiments, the issuer computer may generate more than one digital currency.
- the digital currency held by the issuer computer 106 may be contained in an issuer mobile wallet 106a. In some embodiments, the issuer computer 106 may be a distributor computer.
- the redeemer computer 108 may include a processor and a readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor for performing the functionality described herein.
- the redeemer computer 108 may be an entity that is capable of receiving digital currency and returning the digital currency to the issuer computer 106 in exchange for a fiat currency (or an alternative unit of value).
- the amount of the fiat currency received by the redeemer computer 108 may be based on the amount of the digital currency returned, previously established conversion rates between the digital currency and the fiat currency and/or based on contractual agreements between the issuer computer 106 and the redeemer computer 108.
- the digital currency held by the redeemer computer 108 may be contained in an redeemer mobile wallet 108a
- the issuer computer 106 and the redeemer computer 108 may each maintain a sub-ledger 106c and 108c of the transactions performed using the digital currency and rules established for the digital currency in the system 100.
- the sub-ledgers 106c and 108c may include a list of transactions with each entry including a sender address, a receiver address, and an amount of digital currency for each transaction.
- each sub-ledger 106c and 108c may include only entries related to transactions performed by their respective computers.
- the redeemer sub-ledger 108c may store only those entries from the master ledger database 1 10c that relate to transactions involving the redeemer computer 108.
- 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 1 10c stored in the payment processor computer 1 10.
- the issuer computer 106 may store the read-only copy of the master ledger database 1 10c for audit purposes so as to be aware of all transactions that involved the digital currency generated and distributed by the issuer computer 106.
- storing a sub-ledger may be optional. For example, in some embodiments, only some of the entities in the system 100 may have a sub-ledger. In other embodiments, all or none of the entities in the system 100 may have a sub-ledger. In such embodiments, an entity may request a sub-ledger be generated by the payment processor computer 1 10 through a subscription process. The payment processor computer 1 10 may not generate any sub-ledgers unless it receives a request from one of the entities in the system 100, and may only maintain the master ledger database 1 10c.
- FIG. 2 shows a detailed block diagram for a payment processor computer 1 10 according to an embodiment of the present invention.
- the payment processor computer 1 10 may be associated or operated by a payment processing system.
- the payment processor computer 1 10 may include a processor 1 10a and a computer readable medium 1 10b coupled to the processor 1 10a, the computer readable medium 1 10b comprising code, executable by the processor 1 10a for performing the functionality described herein.
- the computer readable medium 1 10b may comprise code for a plurality of modules, including an authentication module 1 10b-1 , a key generation module 1 10b-2, a transaction validation module 1 10b-3, and a data output module 1 10b-4.
- the processor 1 10a and the authentication module 1 10b-1 may, in conjunction with each other, be configured to perform authentication processes.
- the authentication processes may include determining whether a request message received from a computer is from an entity that should be granted the rights of an issuer (capable of generating and distributing digital currency), a redeemer (capable of receiving digital currency and redeeming the digital currency with the issuer for a fiat currency), or a holder (capable of performing transactions with the digital currency).
- a first entity may have multiple rights such that it may generate a first digital currency as well as perform transactions using or redeeming a second digital currency generated by a second entity.
- the rights granted to an entity may be determined based on identification data for the entity in the request message, or otherwise based on a contractual agreement.
- the authentication process may also include authenticating a request message from an entity in the system 100 to determine whether the node is an issuer, a holder or a redeemer.
- the processor 110a and the authentication module 1 10b-1 may evaluate a received message digitally signed using a first key of a key pair (e.g., a private key of the sender) by decrypting the message using a stored second key of the key pair (e.g., a public key of the sender). By verifying the digital signature of the received message using the second key of the sender to decrypt the message, the processor 1 10a and the authentication module 1 10b-1 may determine the authenticity of the message as being from the holder of the corresponding first key.
- a key pair e.g., a private key of the sender
- a stored second key of the key pair e.g., a public key of the sender
- the processor 1 10a and the authentication module 1 10b-1 determine that the request message was received from a validated entity within the system, the processor 1 10a and the authentication module 1 10b-1 can determine the role (e.g., issuer, holder, redeemer) corresponding to the entity that sent the request message.
- the role e.g., issuer, holder, redeemer
- the processor 1 10a and the key generator module 1 10b-2 in the payment processor computer 1 10 may be configured to generate and distribute digital
- a first key of the key pair (e.g., a public key) may be sent to the entity associated with the key, and a second key of the key pair (e.g., a private key) may be stored in a profile for the entity in an entity profiles database 1 10d at the payment processor computer 1 10.
- the key pair may be used to identify the entity as being an issuer, a holder, a redeemer or an issuing partner such that when the entity transmits a request to generate or issue digital currency, the payment processor computer 1 10 may determine whether the entity is an issuer that is authorized to generate and issue the digital currency, or whether the entity is another type of entity that is not authorized to generate or issue the digital currency.
- the key pair may be an asymmetric key pair. It is also possible to use symmetic key pairs in embodiments of the invention. However, in other embodiments, the key pair may be generated using any other appropriate algorithms.
- the key pair may be an asymmetric key pair such that the public key may be used to encrypt a message sent from an entity to the payment processor computer 1 10, and the corresponding private key for that entity may be used by the payment processor computer 1 10 to decrypt the message.
- the key pair may be generated by the payment processor computer 1 10 in response to a request message from an entity (e.g., issuer computer 106) to create a digital currency (e.g., points) system and to be designated as an entity with the rights to generate and distribute the digital currency in the system 100.
- entity e.g., issuer computer 106
- digital currency e.g., points
- the processor 1 10a and the transaction validation module 1 10b-3 may be configured to evaluate a transaction message received from entities in the system 100 and determine where the transaction contained in the transaction message are valid.
- the processor 1 10a and the transaction validation module 110b-3 may also be configured to generate a ledger entry in the master ledger database 1 10c (stored in a data store) indicating the approval of the transaction, in response to determining that the transaction is validated.
- the processor 1 10a and the transaction validation module 110b-3 may also be configured to evaluate transaction messages related to generating digital currency, redeeming digital currency, and establishing rules associated with generated digital currency
- the payment processor computer 1 10 may receive a transaction message from one or more entities involved in the transaction. For example, for a transaction to transfer digital currency (e.g., points) from the issuer mobile wallet 106a to the holder A mobile wallet 102a, the processor 1 10a and the transaction validation module 1 10b-3 may receive a transaction message indicating the transaction has occurred. The transaction message may be sent by the issuer computer 106 and/or the holder A computing device 102.
- digital currency e.g., points
- the processor 1 10a and the data output module 1 10b-4 may be configured to generate and send messages to the holder computing devices 102 and 104, the issuer computer 106, and the redeemer computer 108.
- the data output module 150b-4 may generate and send response messages to the entities in response to received request messages to generate key pairs and/or request messages indicating that an entity is requesting to generate, distributed, transact with, or redeem an amount of digital currency.
- the response message generated and sent by the data output module 150b-4 may include an indication as to whether the entity that sent the request message is an issuer and authorized to issue and generate the digital currency.
- the payment processor computer 1 10 may be coupled to a master ledger database 1 10c and entity profiles database 1 10d.
- the master ledger database 1 10c may be or contain a distributed ledger that includes entries for all transactions that occur within the system 100 between the various entities.
- the master ledger database 1 10c may include at least two types of entries: transaction entries and rule entries.
- Transaction entries may be records of changes of ownership of digital currency, such as when the issuer associated with the issuer computer 106 issues digital currency to a holder associated with holder A computing device 102, or when the holder associated with holder A computing device 102 transfers an amount of digital currency to a redeemer computer 108 as part of a transaction.
- Rule entries may be records indicating rules associated with the use of particular digital currency. Rules that may be stored in rule entries may include rules regulating redemption and/or transference of the digital currency, conversion rates of the digital currency, and starting/ending dates of rules. In some embodiments, the rules may define an expiration data for the data elements, effective dates for the data elements, limited-time values of the data elements, limits on their use (based on geographical location), the conversion or exchange rate, limits on the entity that can use or accept the data elements. In some embodiments, one or more rules may be associated with the data elements. [0071] In some embodiments, each ledger entry in the master ledger database 1 10c may represent a single event (e.g., a transaction, a rule definition) that was performed within the digital currency system.
- a single event e.g., a transaction, a rule definition
- each ledger entry may be placed in the master ledger database 1 10c in the order the events were received by the payment processor computer 1 10.
- Each ledger entry may be appended to the master ledger database 1 10c by cryptographically signing the ledger entry using the new ledger entry and the previous ledger entry in the master ledger database 1 10c.
- the entity profiles database 1 10d may store a profile for each entity or node within the system 100.
- the profile for each entity may include the a copy of the private/public key that was previous sent to the entity.
- the profile may also include information regarding 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).
- the profile for each entity may also store financial information associated with the entity (e.g., financial institution name, bank identification number, account number).
- financial information may be used as part of the redemption process between the redeemer computer 108 and the issuer computer 102.
- the redeemer computer 108 attempts to redeem the digital currency with the issuer computer 102 for a fiat currency
- the financial information may be retrieved and used for conducting the transfer of funds from the issuer computer 106 to the redeemer computer 108.
- the issuing partner computer 1 14 may be associated with a user or entity that has a contractual relationship with the issuer computer 106 that generates the digital currency. In such embodiments, the issuing partner computer 1 14 may receive an 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 1 14 may include a partner mobile wallet 1 14a to store and maintain the digital currency, a partner private key 1 14b for encrypting messages, and a partner sub-ledger 1 14c for storing records of transactions relevant to the issuing partner computer 1 14. Additional details of the partner mobile wallet 1 14a, the partner private key 1 14b, and the partner sub-ledger 1 14c can be found previously with respect to the holder A computing device 102.
- Embodiments of the present invention utilize a master ledger database 1 10c stored at a payment processor computer 1 10 to store and maintain records of all transactions related to a digital currency, in addition to all rules related to the digital currency.
- the master ledger database 1 10c may include two types of entries:
- Transaction entries may be records indicating the changes of ownership of digital currency, such as when the issuer associated with the issuer computer 106 issues digital currency to a holder associated with holder A computing device 102, or when the holder associated with holder A computing device 102 transfers an amount of digital currency to a redeemer computer 108 as part of a transaction.
- transaction entries for a particular transaction may be private to the entities participating in the particular transaction and to the payment processor computer 1 10.
- a transaction entry may include one or more rules regarding the digital currency when the rules will not change over time.
- Rule entries may be records indicating rules associated with the use of particular digital currency that may change over time, such as an exchange rate. Rules that may be stored in rule entries may include rules regulating redemption and/or transference of the digital currency, conversion rates of the digital currency (e.g., conversion rate between the digital currency and a fiat currency), and starting/ending dates applicable to stored rules. Rules may also be used to encapsulate agreements made between entities in the digital currency system.
- a new rule entry in the master ledger database 1 10c may be placed into effect. In such a scenario, the prior rule being replaced becomes locked and will not apply for future transactions.
- the new ledger entry may be signed and/or encrypted depending on the parties to the new ledger entry and the purpose of the new ledger entry. Transactions may be signed by the two participants to the transaction, as well as encrypted such 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) may be signed and encrypted by the issuer and the redeemer. Public rule entries may be signed only by the issuer and are not typically encrypted. Exchange rates related to transactions between a holder and a redeemer may be signed by the redeemer. If the exchange rate rules require approval, the new ledger entry may also be signed by the issuer.
- the master ledger database 1 10c stored at the payment processor computer 1 10 may only be updated by the payment processor computer 1 10. Read only copies of the master ledger database 110c may be distributed as sub-ledgers.
- the issuer computer 106 may store an issuer sub-ledger 106c that may include all the entries included in the master ledger database 1 10c.
- the issuer computer 106 may need to have knowledge of all aspects of the events (e.g., transactions and rules).
- other entities in the digital currency system e.g., holders, redeemers
- the holder computer(s) and the redeemer computer may store a holder sub-ledger(s) (102c and 104c) and a redeemer sub-ledger 108c, respectively.
- These sub-ledgers may also be read-only copies, but may include fewer ledger entries than in the full master ledger database 1 10c or issuer sub-ledger 106c.
- each of the sub-ledgers may provide the entity with the data (e.g., ledger entries) that they may need to validate their own activity.
- the sub-ledgers may be encrypted such that only the entity in possession of the sub-ledgers and having the private key can decrypt their own sub-ledger.
- holder A computing device 102 may decrypt the holder A sub-ledger 102c using the holder A private key 102b.
- All sub-ledgers, except those that are public sub- ledgers may be encrypted such that only the entity associated with a particular sub- ledger may access the particular sub-ledger.
- the payment processor computer 1 10 may replicate the new ledger entry from the master ledger database 1 10c to generate an entry that can be distributed to the sub-ledgers.
- the payment processor computer 1 10 may then generate a hash using the new ledger entry in the master ledger database 1 10c and a nonce (i.e., a 32- bit field having a random or pseudo-random value).
- a nonce i.e., a 32- bit field having a random or pseudo-random value.
- the payment processor computer 1 10 may then digitally sign the replicated ledger entry.
- the signed replicated ledger may then be distributed to the sub-ledgers for the entities involved in the transaction either via a publish/subscribe mechanism, or manually by the entities.
- FIG. 3 shows a flow diagram of a method of enrollment and key generation within a digital currency program according to an embodiment of the present invention.
- two holder computing devices 102 and 104
- a single issuer computer 106 and a single redeemer computer 108 are depicted in FIG. 3 (the same applies to other subsequently depicted flow diagrams), in other embodiments there may be a fewer number or a greater number of such components.
- step 302 the issuer computer 106 transmits a request message to a payment processor computer 110 to create a digital currency system.
- the request message may be sent to the payment processor computer 1 10 across a
- the payment processor computer 1 10 may determine the identity of the issuer computer 106 that sent the request message.
- the issuer computer 106 may be associated with an entity, such as a merchant or a financial institution, that is requesting the creation of a digital currency program using data elements (e.g., points) with which a value is associated. The value associated with the data elements 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 be designated as an issuer within the digital currency system.
- the payment processor computer 1 10 may evaluate a merchant identifier (e.g., merchant identification number, merchant name) or bank identification number (BIN) associated with the request message to determine whether the issuer computer 106 should be designated as an issuer.
- a merchant identifier e.g., merchant identification number, merchant name
- BIN bank identification number
- the payment processor computer 1 10 may create a master ledger database 1 10c associated with the digital currency system and generate public/private key pair for the issuer computer 106.
- the payment processor computer 1 10 may initiate the process of establishing the digital currency system for the issuer computer 106.
- the payment processor computer 110 may generate a unique digital certificate and a key pair for the issuer computer 106.
- the first key and the second key may be generated using an asymmetric key pair algorithm.
- the first key and the second key may also be generated using other means, as one of ordinary skill in the art would understand.
- the keys of the key pair may be a numeric or alphanumeric value.
- the first key and the second key may be associated with a profile of the issuer computer 106 stored in an entity profiles database 1 10d.
- the key pair may be functionally akin to a conventional public and private key pair, with the first key being equivalent to a public key.
- the first key may differ from a typical public key in that the first key may not be publicly disclosed or broadcast to any other entity or computer other than the entity associated with the key pair.
- the first key may be encrypted prior to being sent to the issuer computer 106 via the communications network 1 12 to ensure that if the first key is intercepted, it cannot be used unless the interceptor has the appropriate decryption key.
- the first key may be used by the issuer computer 106 to verify to the payment processor computer 1 10 that the issuer computer 106 is an issuer and thus has the right to generate and distribute digital currency.
- the payment processor computer 1 10 may also generate the master ledger database 1 10c for the digital currency system. In some embodiments, there may be a single master ledger database 1 10c for the digital currency system.
- each copy of the master ledger database 1 10c stored by the payment processor computer 1 10 may be stored on different server computers.
- the payment processor computer 1 10 may generate a ledger entry 1 10c-1 (as shown in FIG. 7) indicating the enrollment of the issuer computer 106 in the digital currency system.
- the ledger entry 1 10c-1 for the enrollment of the issuer computer 106 may be an indication that the issuer computer 106 has the liability for the digital currency system.
- the ledger entry 1 10c-1 may be entered as the first data entry in the master ledger database 1 10c. In some embodiments, this ledger entry 1 10c-1 may be similar to a public rule and digitally signed using the private key of the issuer computer 1 10c. In this manner, the ledger entry 1 10c-1 can be verified using the public key of the issuer computer 1 10c. In some embodiments, the ledger entry 1 10c-1 may also be signed by the payment processor computer 1 10 to indicate that the ledger entry 1 10c-1 has been processed and validated by the payment processor computer 1 10. [0092] In step 306, the payment processor computer 1 10 may transmit the key pair (e.g.
- the issuer sub-ledger 106c may be a read-only copy of the master ledger database 1 10c stored at the payment processor computer 1 10. In such embodiments, the payment processor computer 1 10 may send all entries to the master ledger database 1 10c to the issuer computer 106. In other embodiments, the issuer sub-ledger 106c may include a sub-set of the entries in the master ledger database 1 10c. For example, in some embodiments, once the issuer computer 106 has distributed the digital currency, the issuer sub-ledger 106c may include only ledger entries related to rules governing the digital currency. For example, this may include rules specifying how redemption of the digital currency by the redeemer computer 108 with the issuer computer 110 is conducted.
- the payment processor computer 1 10 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 1 10 containing updates to the issuer sub-ledger 106c when modifications are made to the master ledger database 1 10c. In such embodiments, changes to the master ledger database 1 10c may be pushed out to the issuer sub-ledger 106c.
- the payment processor computer 1 10 may transmit a first update to the issuer sub-ledger 106c, the first update including the first data entry.
- the payment processor computer 1 10 may replicate the first data entry from the master ledger database 1 10c.
- the payment processor computer 1 10 may then generate a hash using the first data entry in the master ledger database 1 10c and a nonce to generate the first update.
- the payment processor computer 1 10 may then digitally sign the first update prior to transmitting the first update to the issuer computer 106.
- the issuer sub-ledger 106c may be created any time subsequent to the payment processor computer 110 generating the private and public key for the issuer computer 106 and prior to any transaction.
- the issuer sub-ledger 106c may not be created until an initial transaction is performed by the issuer computer 106, such as a points generation process.
- the same may also apply to the other entities in the system 100 (e.g., the holder A sub-ledger 102c may not be created until a transaction where holder A is issued points by the issuer computer 106).
- the payment processor computer 1 10 may receive request messages requesting public/private keys be generated for additional entities for enrollment in the digital currency system.
- the request message may be sent to the payment processor computer 1 10 across a communications network 1 12 using an appropriate communications channel and communications protocol.
- the payment processor computer 1 10 may determine the identity of the requestors that sent the request messages. For example, the payment processor computer 1 10 may receive requests from a holder A computing device 102, a holder B computing device 104, and a redeemer computer 108.
- the requests from the entities may indicate the type of role each entity is requesting within the digital currency system.
- the request from the holder A computing device may request to be a holder within the digital currency system.
- 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 entities are requesting to enroll in the program created by the issuer computer 106.
- the request may include an identifier associated with the issuer computer 106 or for the system (e.g., an identifier to the master ledger database 1 10c for a particular program).
- the issuer computer 106 may only distribute the identifier to entities that it authorizes to enroll in its program.
- the payment processor computer 1 10 may 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 1 10 may also generate ledger entries for each of the enrollments into the digital currency system. This process may be performed in a manner similar to as described above with respect to the issuer computer 106.
- the payment processor computer 1 10 may generate the key pairs for the other entities based on the request received in step 308.
- the payment processor computer 1 10 may generate ledger entries (as shown in FIG. 7) indicating the enrollment of the holder A computing device 102 (ledger entry 1 10c-2), the holder B computing device 104 (ledger entry 1 10c-3), and the redeemer computer 108 (ledger entry 1 10c-4) in the digital currency system.
- the ledgers entries (1 10c-2, 110c-3, and 1 10c-4) may be signed using the private key of the issuer computer 106 and the private key of the corresponding entity (e.g., the ledger entry 1 10c-2 is signed using the private keys associated with the issuer computer 106 and the holder A computing device 102).
- the ledger entry 1 10c-2 may also be signed by the payment processor computer 1 10 to indicate that the ledger entry 1 10c-2 has been processed by the payment processor computer 1 10.
- the ledger entries indicating the enrollment of the entities may be appended to the master ledger database 110c using a hashing technique. For example, when a new ledger entry is to be appended to the master ledger database 1 10c, a hash of the previous ledger entry (e.g., ledger entry 1 10c-1 ) and optionally all other prior ledger entries may be combined with a hash of the new ledger entry (e.g., ledger entry 1 10c-2). In such embodiments, using the hash of the previous ledger entry allows the system to maintain a sequence of ledger entries that can prevent tampering with previous entries.
- a hash of the previous ledger entry e.g., ledger entry 1 10c-1
- a hash of the new ledger entry e.g., ledger entry 1 10c-1
- a hash of the new ledger entry e.g., ledger entry 1 10c-2
- using the hash of the previous ledger entry allows the system to maintain a sequence of led
- the payment processor computer 1 10 may transmit the generated private keys to the corresponding holder A computing device 102, holder B computing device 104, and redeemer computer 108.
- the payment processor computer 1 10 may also transmit the appropriate sub-ledger entries to each of the holder A computing device 102, the holder B computing device 104, and the redeemer computer 108.
- the sub-ledger entries sent to each of the holder A computing device 102, the holder B computing device 104, and the redeemer computer 108 may be different.
- each entity may only receive ledger entries from the master ledger database 110c that are related to the entity.
- the holder A sub-ledger 102A may only include ledger entries for transactions in which the holder A computing device 102 is a participant, as well as rules that are applicable to the digital currency contained in the holder A mobile wallet 102a.
- the payment processor computer 1 10 may provide information to the entities to allow an application running their respective sub- ledgers (102c, 104c, and 108c) to subscribe to receive messages from the payment processor computer 1 10 containing updates to their respective sub-ledgers when modifications are made to the master ledger database 1 10c.
- the first update and the second update may be automatically transmitted to the issuer sub- ledger 108 based on a predetermined schedule.
- the digital currency system may be configured for operation.
- additional entities may be added or removed from the digital currency system at any time, and any of these above-described steps may again be performed by the payment processor computer 1 10.
- FIG. 4 shows a flow diagram 400 of a method of generating digital currency by an issuer according to an embodiment of the present invention.
- the issuer computer 106 may transmit a request message to create data elements (e.g., points) for the digital currency system, and the payment processor computer 1 10 may subsequently receive the request message via a communications network 1 12.
- the request message may also include a first amount of the data elements to be generated.
- the request message itself may also be encrypted by the issuer computer 106 prior to being sent to the payment processor computer 1 10.
- the request message may be digitally signed using a private key associated with the issuer computer 106 previously generated by the payment processor computer 1 10.
- the issuer computer 106 may use a hash algorithm with the request message to generate a hash value.
- the issuer computer private key 106b is used with an encryption algorithm to generate a digital signature.
- the issuer computer 106 may perform the steps to generate and issue the data elements. In some embodiments, this process may occur algorithmically (e.g., according to a schedule, according to market conditions, according to a value of an associated fiat currency) or at the request of a user controlling the issuer computer 106.
- the issuer computer 106 may have signed a transaction to itself for the first amount of the data elements, and subsequently deposited the first amount of the data elements in the issuer mobile wallet 106a.
- Merchant A associated with the issuer computer 106 may have deposited 100,000 points into the issuer mobile wallet 106a.
- the issuer computer 106 may generate the data elements in a variety of ways, including but not limited to sending the amount of data elements to itself as part of a payment transaction message.
- the issuer computer 106 may generate a first payment transaction message with the source and destination address, which may be the address of the issuer computer 106.
- the first payment transaction message may include an amount of data elements (e.g., 100,000 points).
- the payment processor computer 1 10 may validate that the issuer was in possession of the issuer private key 106b and create an entry in the master ledger database 1 10c representing the transaction generating the data elements.
- the payment processor computer 1 10 may validate the private key used to sign the request message by using the corresponding public key of the issuer computer 106.
- the payment processor computer 1 10 may validate the digital signature by verifying the received digital signature using the issuer public key to generate a first hash value. The payment processor computer 1 10 may then use the same hash algorithm used by the issuer computer 106 on the request message to generate a second hash value. When the first hash value and the second hash value match, the digital signature is validated.
- the payment processor computer 1 10 will know that the request message was sent by a legitimate issuer of the digital currency system.
- the payment processor computer 1 10 may determine whether the issuer computer 106 is authorized to generate and issue digital currency. In some embodiments, the payment processor computer 1 10 may retrieve a profile associated with the issuer computer 106 from the entity profiles database 1 1 Od using identifying information associated with the issuer computer 106. In some embodiments, the payment processor computer 1 10 may retrieve a second key (e.g., a public key) of the key pair from the retrieved profile for the issuer computer 106.
- a second key e.g., a public key
- the processor and an authentication module 1 10b-1 may determine the request message was received from an authorized issuer computer 106 by determining whether the request message was digitally signed using a first key that can be decrypted using a second key associated with the authorized issuer computer 106.
- the request message may be encrypted by the issuer private key 106b (e.g., the first key) prior to being sent by the issuer computer 106.
- the determination as to whether the request message was made by an authorized issuer node may be made by using an issuer public key (e.g., the second key) stored at the payment processor computer 1 10 to verify that the request message was digitally signed by the legitimate issuer computer 106.
- the payment processor computer 1 10 may also generate a ledger entry 1 10c-5 (as shown in FIG. 7) indicating the generation and issuance of a value token A.
- the generated ledger entry will include the hash that was digitally signed using the issuer private key 106b of the issuer computer 106 and then be digitally signed using a private key of the payment processor computer 1 10. In such embodiments, this may be an indication that the generated ledger entry is a legitimate entry for a legitimate transaction.
- the payment processor computer 1 10 may generate and send a response message to the issuer computer 106 indicating this.
- the response message may be the sub-ledger update sent to the issuer computer 106 by the payment processor computer 1 10, as described below.
- the issuer computer 106 may then generate the digital currency.
- the issuer computer 106 may generate and issue digital currency by establishing an amount of digital currency to create and a currency conversion rate between a unit of the digital currency and a fiat currency (e.g., the U.S. Dollar, the British Pound). For example, one unit of the digital currency may be the equivalent to one U.S. Dollar.
- value token A may be stored in the issuer mobile wallet 106a representing the amount of digital currency created by the issuer computer 106.
- the ledger entry 1 10c-5 may include data indicating that value token A is stored in the issuer mobile wallet 106a.
- the payment processor computer 1 10 may transmit an update to the issuer sub-ledger 106c including the entry to the master ledger database 1 10c.
- the update to the issuer sub-ledger 106c is sent based on preferences associated with the issuer computer 106 and/or when requested by the issuer computer 106.
- the update to the issuer sub-ledger 106c may be sent as part of a subscription process where the updates are sent a pre- established time or interval.
- the update to the issuer sub-ledger 106c may be encrypted by the payment processor computer 1 10 prior to being sent to the issuer computer 106.
- the update to the issuer sub-ledger 106c may be encrypted using an 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.
- the issuer computer 106 transmits a rules message to the payment processor computer 1 10 to create rules for the points previously generated.
- the rules message may be digitally signed using a private key associated with the issuer computer 106 previously generated by the payment processor computer 1 10.
- the rules message may also include a first amount of the data elements to be generated.
- the rules message itself may also be encrypted by the issuer computer 106 prior to being sent to the payment processor computer 1 10.
- the rules message may include one or more rules governing the use of the points previously generated by the issuer computer 106.
- the data elements are points having a value defined by the rule.
- the issuer computer 106 may generate the rules message after generating the points. In other embodiments, the issuer computer 106 may transmit the rules message to the payment processor computer 1 10 prior to generating the points.
- the payment processor computer 1 10 may validate the issuer private key and create an entry in the master ledger database 1 10c representing the rules applicable to the generated data elements.
- the payment processor computer 1 10 may validate 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 validated, the payment processor computer 1 10 will know that the request message was sent by a legitimate issuer of the digital currency system.
- the payment processor computer 1 10 may generate one or more ledger entries 1 10c-6 and 110c-7 (as shown in FIG. 7) indicating the rules associated with the generated data elements.
- the ledger entries 1 10c-6 and 1 10c-7 generated based on the rules message may be public entries that can be viewed by both participants and non-participants to the digital currency system.
- the issuer computer 106 may have a default conversion rate between the value of one unit of the data elements and U.S. Dollars, and this rule would be applicable to all entities in the system.
- the rules in the ledger entries 110c-6 and 1 10c-7 may be added to the master ledger database 1 10c to be used with future transactions that match criteria associated with the digital currency.
- the generated ledger entry for the rules will include the hash that was digitally signed using the issuer private key 106b of the issuer computer 106 and then be digitally signed using a private key of the payment processor computer 1 10. In such embodiments, this may be an indication that the generated ledger entry is a legitimate entry for a legitimate rule created by the issuer computer 106.
- the payment processor computer 1 10 may transmit an update to the issuer sub-ledger 106c including the rules entry (1 10c-6 and 1 10c-7) to the master ledger database 1 10c.
- the update to the issuer sub- ledger 106c may be sent based on preferences associated with the issuer computer 106 and/or when requested by the issuer computer 106.
- the rules entries may be distributed to appropriate sub-ledgers, including one or more public sub-ledgers. Public sub-ledgers may contain all the rule entries that are publicly available, and may be accessible non-participants in the digital currency system, as well as to participants.
- the update the issuer sub-ledger 106c (e.g., the second data entry) may be signed using the private key of the issuer computer 106 prior to being appended to the issuer sub-ledger 106c.
- the issuer sub-ledger 106c and the redeemer sub- ledger 108c may 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 may be a rule governing the conversion rate for digital currency that only applies to redeemer computer 108 that may be different from the default conversion rate. The ledger entry for this rule would be included in the issuer sub- ledger 106c and the redeemer sub-ledger 108c, and may be excluded from the sub- ledgers of other entities in the system.
- the ledger entries representing rules agreed to by the issuer computer 106 and the redeemer computer 108 may be digitally signed using both the issuer private key 106c and the redeemer private key 108c.
- the issuer computer 106 may update rules that have been previously added to the master ledger database 1 10c. In such
- the issuer computer 106 may generate an update rules message.
- the update rules message may be digitally signed using the private key of the issuer computer 106 and may include information related to a modification to a rule.
- the issuer computer 106 may send the update rules message to the payment processor computer 1 10.
- the payment processor computer 1 10 may validate the update rules message using the public key associated with the first entity computer and corresponding to the private key. When the update rules message is validated, the payment processor computer 1 10 may update the master ledger database 1 10c to include a new rules entry including the modification to the rule.
- the payment processor computer 1 10 may then transmit the new rules entry to the issuer sub-ledger 106c, and to any other appropriate sub-ledgers, including one or more public sub-ledgers.
- FIG. 5 shows a flow diagram 500 of a method of transferring digital currency from an issuer of the digital currency to a holder according to an embodiment of the present invention.
- the issuer may transfer digital currency to issue digital currency to the holder in response to a transaction performed by the holder.
- the issuer may transfer digital currency to the holder for a completed trip using the airline.
- the issuer may transfer digital currency for transactions performed by the holder using a linked financial account.
- the issuer computer 106 may transmit 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.
- the issuer computer 106 may generate a transaction message with the source address being an address of the issuer computer 106, and destination address of the being the address of the Holder A computing device 102.
- the issuer computer 106 may request the address of the Holder A computing device 102 from the payment processor computer 1 10. In such
- the payment processor computer 1 10 may store the address of the Holder A computing device 102 from the entity profiles database 11 Od.
- the entity profiles database 1 10d may function as a directory of entities in the system 100.
- the issuer computer 106 may then store the address of the Holder A computing device 102 for future transactions.
- the issuer computer 106 may create a transaction to transfer an amount of the data elements to one of the holders (e.g., holder A computing device 102). For example, assuming the issuer computer 106 previously generated 100,000 units of the digital currency, the issuer computer 106 may want to transfer 500 units of the digital currency to the holder A computing device 102. In order to distribute the 500 units of the digital currency to holder A computing device 102, the issuer computer 106 may generate a second transaction message including the address of the issuer computer 106, the address of the holder A computing device 102, and the amount of the digital currency (e.g., 500 units).
- the issuer computer 106 may generate a second transaction message including the address of the issuer computer 106, the address of the holder A computing device 102, and the amount of the digital currency (e.g., 500 units).
- the transaction message may be encrypted by the issuer computer 106 using a 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 validated using the public key of the issuer computer 106 to determine that the transaction is valid and from the authentic issuer computer 106. The transaction message may then be sent to the holder A computing device 102.
- step 504 the holder A computing device 102 and the issuer computer 106 may update their respective mobile wallets (102a and 106a). In some
- the holder A mobile wallet 102a may be updated to include the 500 units of digital currency from the issuer computer 106, and the issuer mobile wallet 106a may be updated to decrease the digital currency by the 500 units.
- updating the holder A mobile wallet 102a may also include assigning a value token (e.g., value token A) from the issuer mobile wallet 106a to the holder A mobile wallet 102a.
- the payment processor computer 1 10 may receive a transaction message including details for the transfer or distribution of data elements (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 1 10 via the communications network 1 12.
- the payment processor computer 1 10 may receive the transaction message after the holder A mobile wallet 102a and the issuer mobile wallet 106a has been updated.
- the payment processor computer 1 10 may receive the transaction message prior to the holder A mobile wallet 102a and the issuer mobile wallet 106a being updated.
- the payment processor computer 1 10 may validate the transaction received in the transaction message.
- the payment processor computer 1 10 may validate 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.
- the payment processor computer 1 10 will know that the request message was sent by a legitimate issuer of the digital currency system.
- the payment processor computer 1 10 may create a ledger entry in the master ledger database 1 10c for the transaction received in the transaction message.
- the payment processor computer 1 10 may generate ledger entry 1 10c-8 (as shown in FIG. 7), evidencing the transfer of value token A from the issuer computer 106 mobile wallet 106a, to the holder A computing device 102 mobile wallet 102a.
- the ledger entry may be digitally signed using the private keys of the issuer computer 106 and holder A computing device 102, as parties to the transaction, and using the private key of the payment processor computer 1 10 to indicate that the transaction has been validated and the entry is legitimate.
- the payment processor computer 1 10 may initiate the process of updating the appropriate sub-ledgers.
- the payment processor computer 1 10 may transmit an update to the issuer sub-ledger 106c and the holder A sub-ledger 106a, as the associated computers were involved in the transaction.
- the issuer sub-ledger 106c may also be updated with the transaction.
- the payment processor computer 1 10 may send the ledger entry (1 10c-8 in the master ledger database 1 10c) indicating that the transfer of value token A from the issuer computer 106 mobile wallet 106a, to the holder A computing device 102 mobile wallet 102a, was performed.
- the holder A sub-ledger 102c may include a sub-set of the entries in the master ledger database 1 10c. For example, in some embodiments, once the
- the holder A sub-ledger 102c may be updated to include the ledger entry evidencing the transaction (e.g., 1 10c-8).
- the holder A sub-ledger 102c may include only ledger entries related to transaction related to the holder A computing device 102 as well as to rules governing the digital currency. For example, this may include rules specifying any details regarding the digital currency (e.g., expiration date, transacting value with one or more redeemers).
- FIG. 6 shows a flow diagram 600 of a method of a redeemer redeeming digital currency with an issuer of the digital currency according to an embodiment of the present invention.
- the redeemer computer 108 may want to redeem digital currency that it received from a holder (e.g., the holder A computing device 102) as part of a transaction process between the holder and redeemer.
- a holder e.g., the holder A computing device 102
- holder A may have
- the holder A computing device 102 may interact with the redeemer computer 108 to communicate the transfer of 400 data elements.
- the process of transferring data elements between a holder (e.g., holder A) and a redeeming partner may be performed in a manner similar to that described with respect to the transfer of data elements from the issuer computer 1 10 to the holder A computing device 102.
- 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.
- data elements e.g., points
- a value token B may be generated.
- the payment processor computer 1 10 may also generate a ledger entry 1 10c-9 (as shown in FIG. 7) indicating the generation and issuance of value token B.
- value token B may be stored in the holder A mobile wallet 102a, and the ledger entry 1 10c-9 may include data indicating that value token B is stored in the holder A mobile wallet 102a.
- the master ledger database 1 10c may also include ledger entries for the transaction between holder A computing device 102 and the redeemer computer 108 (e.g.
- the redeemer computer 108 initiates a redemption transaction to redeem data elements (e.g., points) with the issuer computer 106.
- the data elements may be stored as a value token in a mobile wallet 108a associated with the redeemer computer 108.
- the value token may be
- the redeemer computer 108 may transmit a redemption transaction message to the issuer computer 106 to transfer data elements within the digital currency system from the redeemer mobile wallet 108a to the issuer mobile wallet 108a.
- the redeemer computer 108 may generate the redemption transaction message with the source address being an address of the redeemer computer 108, and destination address of the being the address of the issuer computer 106.
- the redeemer computer 108 and the issuer computer 106 may update their respective mobile wallets (108a and 106a).
- the redeemer mobile wallet 108a may be updated to decrease the 400 data elements of digital currency being redeemed with the issuer computer 106, and the issuer mobile wallet 106a may be updated to increase the digital currency by the 400 data elements.
- updating the redeemer mobile wallet 108a may also include assigning a value token (e.g., value token B) from the redeemer mobile wallet 108a to the issuer mobile wallet 106a.
- the payment processor computer 1 10 may receive a redemption transaction message including details for 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 1 10 via the communications network 1 12.
- the payment processor computer 1 10 may validate the redemption transaction received in the redemption transaction message.
- the payment processor computer 1 10 may validate 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.
- the payment processor computer 1 10 will know that the request message was sent by a legitimate redeemer within the digital currency system.
- the payment processor computer 1 10 may retrieve a second data entry (e.g., 1 10c-6 in FIG. 7) from the master ledger database 1 10c, the second data entry indicating one or more rules associated with the redemption of an amount of data elements.
- the data elements may be points having a value defined by the rule.
- the second data entry may include one or more rules that may indicate an exchange rate between the value of the data elements and a fiat currency. For example, a rule may indicate that through an agreement between the redeemer computer 108 and the issuer computer 106, the issuer computer will redeem every ten points possessed by the redeemer computer 108 for $1 .00.
- other rules stored in the master ledger database 1 10c may limit an amount that the redeemer computer 108 may redeem with the issuer computer 108.
- the payment processor computer 1 10 may create a ledger entry in the master ledger database 1 10c for the redemption transaction received in the redemption transaction message.
- the payment processor computer 1 10 may generate ledger entry 1 10c-12 (as shown in FIG. 7), evidencing the transfer of value token B from the redeemer computer 108 mobile wallet 108a, to the holder A computing device 106 mobile wallet 106a.
- the payment processor computer 1 10 may transmit an update to the issuer sub-ledger 106c and the redeemer sub-ledger 108a, as the associated computers were involved in the transaction.
- the payment processor computer 1 10 may send the ledger entry (1 10c-12 in the master ledger database 1 10c) indicating that the transfer of value token B from the holder A computing device 102 mobile wallet 102a, to the issuer computer 106 mobile wallet 106a, was performed.
- a settlement process may be initiated between the issuer computer 106 and the redeemer computer 108.
- the settlement process may be conducted based on the amount of digital currency redeemed by the redeemer computer 108, and one or more rules regarding the digital currency.
- the one or more rules may include a rule defining the conversion of the data elements to a fiat currency (e.g., the United States Dollar, British Pound).
- the payment processor computer 1 10 may retrieve financial account information (e.g., account numbers) for the issuer associated with the issuer computer 106 and the redeemer associated with the redeemer computer 108. In some embodiments, the payment processor computer 1 10, may retrieve the financial account information from the issuer computer 106 and the redeemer computer 108. In other embodiments, the payment processor computer 1 10 may initiate the settlement process by accessing the profiles database to locate profiles associated with the issuer computer 106 and redeemer computer 108 and retrieving financial information for the issuer and redeemer 108 that may have been received as part of the enrollment process.
- financial account information e.g., account numbers
- the payment processor computer 1 10 may retrieve the financial account information from the issuer computer 106 and the redeemer computer 108.
- the payment processor computer 1 10 may initiate the settlement process by accessing the profiles database to locate profiles associated with the issuer computer 106 and redeemer computer 108 and retrieving financial information for the issuer and redeemer 108 that may have been received as part of the enrollment process.
- the settlement process can be performed by the issuer sending payment to the redeemer through alternative means (e.g., check payment).
- the payment processor computer 1 10 may be one of a plurality of payment processor computers.
- each of the payment processor computers may include a master ledger database.
- the payment processor computers may create an entry in the master ledger database evidencing the transaction.
- each payment processor computer of the plurality of payment processor computers may provisionally add a ledger entry, and a reconciliation process may be performed to synchronize the various master ledger databases to ensure that all of the master ledger database include the same entries.
- the payment processor computer may not validate the ledger entry (by digitally signing the ledger entry using the private keys of the plurality of payment processor computers) until there is an agreement between the plurality of payment processor computers as to what the next ledger entry should be.
- Methods of reconciliation and synchronization between the various master ledger databases may be performed in any suitable manner using one or more algorithms or processes as would be understood by one of ordinary skill in the art.
- the rules messages may be sent and stored out of band of the system.
- the rules may not be placed in the master ledger database 1 10c. Instead, the rules may be stored externally from the system 100 and accessed by the entities in the system 100 when a transaction or redemption process is performed.
- default rules stored out of band of the system may be accessed and applied to transactions.
- any ledger entries for rules governing the distribution of the digital currency by the issuing partner computer 114 may be digitally signed using the issuer computer private key 106b and the issuing partner private key 1 14b.
- the ledger entries may also be digitally signed using the redeemer private key 108b.
- the issuer computer 106 may generate digital currency in the form of a coupon value that may be valid and used simultaneously with the data elements (e.g., points) of the digital currency system.
- the coupon value may be generated with an expiration date that indicates the coupon value is valid for a predetermined period of time.
- the coupon may be an agreement between the issuer computer and the redeemer computer that the issuer will buy-back previously issued data elements at a particular rate.
- the coupon may function as a put option, which is an option to sell assets at an agreed price on or before a particular date. For example, issuer A may offer to buy back previously issued data elements at one dollar for every three points if returned prior to December 31 , 2016. IV. TECHNICAL BENEFITS
- Embodiments of the present invention provide a number of advantages and technical benefits.
- the decentralization of the system such that each entity within the system has the data it needs to conduct transactions in its own unique sub- ledger significantly reduces the time and computing resources required to perform transactions. Transactions can be conducted between the entities involves in the transaction, with the details of the transaction sent to a central computer once it is completed for the purpose of validation and storage in a master ledger. This eliminates the need for authorization request messages being sent during a transaction itself and eliminates the friction caused by authentication and authorization processes performed during typical transactions.
- Embodiments of the present invention thus eliminate the need for the extensive infrastructure required in current solutions.
- a single system may be used to managing a plurality of different programs, with the rules for each program embodied in the rules entry in the ledgers.
- embodiments of the claimed invention provide for sub-ledgers that optionally allow an entity within the digital currency system to maintain a sub-set of entries stored at the master ledger.
- the sub-set of entries may include only those relevant to the entity, such as transactions performed by the entity and rules governing the digital currency held by the entity.
- each of the entities e.g., issuer, holder, redeemer
- the payment processing computer must be authenticated and approved by the payment processing computer, ensuring that only specific entities have the right and ability to generate and transact with the digital currency.
- this provides both enhanced security that the digital currency is valid and prevents reduces the risk of fraud involving the digital currency.
- FIG. 8 Examples of such subsystems or components are shown in FIG. 8. Any of the subsystems or components shown in FIG. 8 can be included in any of the previously described devices, apparatuses, or systems.
- the subsystems shown in FIG. 8 are interconnected via a system bus 800. Additional subsystems such as a printer 808, keyboard 816, fixed disk 818 (or other memory comprising computer readable media), monitor 812, which is coupled to display adapter 810, and others are shown.
- Peripherals and input/output (I/O) devices which couple to I/O controller 802 (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as serial port 814.
- serial port 814 or external interface 820 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner.
- the interconnection via system bus allows the central processor 806 to communicate with each subsystem and to control the execution of instructions from system memory 804 or the fixed disk 818, as well as the exchange of information between subsystems.
- the system memory 804 and/or the fixed disk 818 may embody a computer readable medium.
- Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques.
- the software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM.
- RAM random access memory
- ROM read only memory
- magnetic medium such as a hard-drive or a floppy disk
- optical medium such as a CD-ROM.
- Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
- any of the entities described herein may be embodied by a computer that performs any or all of the functions and steps disclosed.
- One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the technology.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Game Theory and Decision Science (AREA)
- Marketing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/961,554 US11270299B2 (en) | 2015-12-07 | 2015-12-07 | Methods and systems of using a cryptocurrency system to manage payments and payment alternatives |
PCT/US2016/060048 WO2017099909A1 (en) | 2015-12-07 | 2016-11-02 | Methods and systems of using a cryptocurrency system to manage payments and payment alternatives |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3387603A1 true EP3387603A1 (en) | 2018-10-17 |
EP3387603A4 EP3387603A4 (en) | 2018-12-19 |
Family
ID=58799173
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP16873533.0A Ceased EP3387603A4 (en) | 2015-12-07 | 2016-11-02 | Methods and systems of using a cryptocurrency system to manage payments and payment alternatives |
Country Status (7)
Country | Link |
---|---|
US (2) | US11270299B2 (en) |
EP (1) | EP3387603A4 (en) |
CN (2) | CN114693301A (en) |
AU (1) | AU2016369243B2 (en) |
HK (1) | HK1256234A1 (en) |
RU (1) | RU2018124778A (en) |
WO (1) | WO2017099909A1 (en) |
Families Citing this family (41)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015123691A1 (en) | 2014-02-14 | 2015-08-20 | Boemi Andrew A | Mobile device payment system and method |
WO2016076934A2 (en) | 2014-08-22 | 2016-05-19 | Thomas John K | Verification system for secure transmission in a distributed processing network |
WO2017127564A1 (en) * | 2016-01-19 | 2017-07-27 | Priv8Pay, Inc. | Network node authentication |
US9794074B2 (en) * | 2016-02-04 | 2017-10-17 | Nasdaq Technology Ab | Systems and methods for storing and sharing transactional data using distributed computing systems |
EP3414713B1 (en) * | 2016-02-12 | 2023-07-26 | Royal Bank Of Canada | Methods and systems for digital reward processing |
US10440101B2 (en) * | 2016-02-22 | 2019-10-08 | Bank Of America Corporation | System for external validation of private-to-public transition protocols |
US11727391B2 (en) * | 2016-04-11 | 2023-08-15 | Nchain Licensing Ag | Computer-implemented methods and systems for validating tokens for blockchain-based cryptocurrencies |
US10432531B2 (en) | 2016-06-28 | 2019-10-01 | Paypal, Inc. | Tapping network data to perform load balancing |
US10067810B2 (en) * | 2016-07-28 | 2018-09-04 | Cisco Technology, Inc. | Performing transactions between application containers |
US10417217B2 (en) * | 2016-08-05 | 2019-09-17 | Chicago Mercantile Exchange Inc. | Systems and methods for blockchain rule synchronization |
US11455642B1 (en) | 2016-09-19 | 2022-09-27 | United Services Automobile Association (Usaa) | Distributed ledger based interchange |
GB2557277A (en) * | 2016-12-02 | 2018-06-20 | Cavendish Wood Ltd | A distributed ledger |
US10762479B2 (en) * | 2017-04-05 | 2020-09-01 | Samsung Sds Co., Ltd. | Method and system for processing blockchain-based real-time transaction |
JP6817132B2 (en) * | 2017-04-11 | 2021-01-20 | 株式会社野村総合研究所 | Point operation system and point operation program |
CN110998631A (en) * | 2017-07-17 | 2020-04-10 | Dlt基数公司 | Distributed account book technology |
US11263603B1 (en) | 2017-07-26 | 2022-03-01 | Square, Inc. | Security asset packs |
US10055715B1 (en) | 2017-07-26 | 2018-08-21 | Square, Inc. | Cryptocurrency payment network |
WO2019043430A1 (en) * | 2017-08-29 | 2019-03-07 | Mundi Maris Ralfs | A system, a method and a currency unit for time degradable currency |
US20190066205A1 (en) * | 2017-08-30 | 2019-02-28 | StartEngine Crowdfunding, Inc. | Peer-to-peer trading with blockchain technology |
US20190122241A1 (en) * | 2017-10-20 | 2019-04-25 | Adp, Llc | Incentive-Based Electronic Messaging System |
US11164181B2 (en) * | 2018-01-12 | 2021-11-02 | Visa International Service Association | Techniques for conducting transactions utilizing cryptocurrency |
US10298585B1 (en) | 2018-01-26 | 2019-05-21 | Accenture Global Solutions Limited | Blockchain interoperability |
US20210099284A1 (en) * | 2018-02-08 | 2021-04-01 | 2Bc Innovations, Llc | Modifying blockchain-encoded records of rived longevity-contingent instruments |
US20210035217A1 (en) * | 2018-02-08 | 2021-02-04 | 2Bc Innovations, Llc | Updating blockchain-encoded records of rived longevity-contingent instruments |
US11315138B1 (en) * | 2018-03-12 | 2022-04-26 | Worldpay, Llc | Decentralized computer systems and methods for loyalty points payments using distributed ledgers |
US10721065B2 (en) | 2018-03-29 | 2020-07-21 | Accenture Global Solutions Limited | Active state blockchain synchronization |
WO2019198427A1 (en) * | 2018-04-10 | 2019-10-17 | 良成 松田 | Virtual currency management system and virtual currency management program |
US10977626B2 (en) * | 2018-06-14 | 2021-04-13 | Capital One Services, Llc | Semi-private blockchain virtual currency exchange systems |
WO2019246627A1 (en) * | 2018-06-22 | 2019-12-26 | Mshift, Inc. | Blockchains for facilitating decentralized fund transfer |
US11763335B2 (en) * | 2018-08-27 | 2023-09-19 | Gemini Ip, Llc | Real-time distribution of cryptocurrency rewards for a loyalty program |
GB201815816D0 (en) * | 2018-09-28 | 2018-11-14 | Nchain Holdings Ltd | Computer-implemented system and method |
US20210374724A1 (en) * | 2018-10-19 | 2021-12-02 | Bell Identification B.V. | Secure digital wallet processing system |
US20200193426A1 (en) * | 2018-12-18 | 2020-06-18 | Secude Ag | Method and system for creating and updating an authentic log file for a computer system and transactions |
US10637644B1 (en) * | 2018-12-21 | 2020-04-28 | Capital One Services, Llc | System and method for authorizing transactions in an authorized member network |
US10861008B2 (en) | 2018-12-21 | 2020-12-08 | Capital One Services, Llc | System and method for optimizing cryptocurrency transactions |
WO2020179863A1 (en) * | 2019-03-05 | 2020-09-10 | Social Good Foundation株式会社 | Information processing device, information processing method, and program |
US11182819B2 (en) | 2019-06-25 | 2021-11-23 | Alef Edge, Inc. | System and method for a digital coin exchange |
US20220343302A1 (en) * | 2019-10-21 | 2022-10-27 | Visa International Service Association | Inter wallet transactions |
US20210312431A1 (en) * | 2020-04-06 | 2021-10-07 | Mastercard Asia/Pacific Pte. Ltd. | Method and system for use of an emv card in a multi-signature wallet for cryptocurrency transactions |
KR102245530B1 (en) * | 2020-04-27 | 2021-04-27 | 윤성민 | International Digital Currency Management system and method thereof |
CN113344684A (en) * | 2021-05-11 | 2021-09-03 | 陈平 | On-line auction method based on intelligent contract, electronic equipment and storage medium |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060253320A1 (en) * | 2005-05-06 | 2006-11-09 | First Data Corporation | Loyalty systems and methods |
US8935187B2 (en) | 2007-03-07 | 2015-01-13 | Playspan, Inc. | Distributed payment system and method |
US8689247B2 (en) * | 2008-04-04 | 2014-04-01 | Qualcomm Incorporated | Systems and methods for distributing and redeeming credits on a broadcast system |
US9818109B2 (en) | 2012-08-16 | 2017-11-14 | Danny Loh | User generated autonomous digital token system |
US11055710B2 (en) * | 2013-05-02 | 2021-07-06 | Visa International Service Association | Systems and methods for verifying and processing transactions using virtual currency |
US20150220928A1 (en) | 2014-01-31 | 2015-08-06 | Robert Allen | Platform for the purchase and sale of digital currency |
KR20150107971A (en) | 2014-03-14 | 2015-09-24 | 최중현 | Method for exchange in real time between mileage and bitcoin |
WO2015142765A1 (en) | 2014-03-17 | 2015-09-24 | Coinbase, Inc | Bitcoin host computer system |
US9830593B2 (en) | 2014-04-26 | 2017-11-28 | Ss8 Networks, Inc. | Cryptographic currency user directory data and enhanced peer-verification ledger synthesis through multi-modal cryptographic key-address mapping |
WO2015175854A2 (en) | 2014-05-15 | 2015-11-19 | Cryptyk, Inc. (Trading As Bitsavr Inc.) | System and method for digital currency storage, payment and credit |
US11164164B2 (en) | 2014-05-15 | 2021-11-02 | Uphold Global Foundation | System and method for converting cryptocurrency to virtual assets whose value is substantiated by a reserve of assets |
US9704143B2 (en) * | 2014-05-16 | 2017-07-11 | Goldman Sachs & Co. LLC | Cryptographic currency for securities settlement |
US20150348017A1 (en) * | 2014-06-03 | 2015-12-03 | Jonathan Allmen | Method for integrating cryptocurrency transfer on a social network interface |
US11055707B2 (en) | 2014-06-24 | 2021-07-06 | Visa International Service Association | Cryptocurrency infrastructure system |
CN104392354B (en) | 2014-11-05 | 2017-10-03 | 中国科学院合肥物质科学研究院 | A kind of public key address is associated and search method and its system with user account |
US11250391B2 (en) | 2015-01-30 | 2022-02-15 | Visa International Service Association | Token check offline |
US11023968B2 (en) * | 2015-03-05 | 2021-06-01 | Goldman Sachs & Co. LLC | Systems and methods for updating a distributed ledger based on partial validations of transactions |
US11392955B2 (en) * | 2015-05-20 | 2022-07-19 | Ripple Luxembourg S.A. | Temporary consensus networks in a resource transfer system |
US20170140408A1 (en) * | 2015-11-16 | 2017-05-18 | Bank Of America Corporation | Transparent self-managing rewards program using blockchain and smart contracts |
-
2015
- 2015-12-07 US US14/961,554 patent/US11270299B2/en active Active
-
2016
- 2016-11-02 CN CN202210358200.9A patent/CN114693301A/en active Pending
- 2016-11-02 AU AU2016369243A patent/AU2016369243B2/en active Active
- 2016-11-02 WO PCT/US2016/060048 patent/WO2017099909A1/en active Application Filing
- 2016-11-02 EP EP16873533.0A patent/EP3387603A4/en not_active Ceased
- 2016-11-02 RU RU2018124778A patent/RU2018124778A/en not_active Application Discontinuation
- 2016-11-02 CN CN201680071832.XA patent/CN108369703B/en active Active
-
2018
- 2018-11-27 HK HK18115172.8A patent/HK1256234A1/en unknown
-
2022
- 2022-01-27 US US17/586,670 patent/US20220156738A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
AU2016369243A1 (en) | 2018-04-12 |
US20170161734A1 (en) | 2017-06-08 |
CN108369703A (en) | 2018-08-03 |
US11270299B2 (en) | 2022-03-08 |
EP3387603A4 (en) | 2018-12-19 |
HK1256234A1 (en) | 2019-09-20 |
US20220156738A1 (en) | 2022-05-19 |
CN108369703B (en) | 2022-04-15 |
CN114693301A (en) | 2022-07-01 |
AU2016369243B2 (en) | 2022-05-19 |
RU2018124778A3 (en) | 2020-04-16 |
WO2017099909A1 (en) | 2017-06-15 |
RU2018124778A (en) | 2020-01-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220156738A1 (en) | Methods and systems of using a cryptocurrency system to manage payments and payment alternatives | |
US11687924B2 (en) | Cryptocurrency infrastructure system | |
US11785079B2 (en) | Free storage protocol for blockchain platform | |
US10652028B2 (en) | Systems and methods for secure detokenization | |
CN106982205B (en) | Block chain-based digital asset processing method and device | |
US11245653B2 (en) | Methods and systems for creating and using massless currency | |
US6157920A (en) | Executable digital cash for electronic commerce | |
US10637644B1 (en) | System and method for authorizing transactions in an authorized member network | |
US6938019B1 (en) | Method and apparatus for making secure electronic payments | |
CN106327173A (en) | Network payment method and network payment device | |
JP2002140630A (en) | System and method for clearing contents charge based on ticket | |
GB2549118A (en) | Electronic payment system using identity-based public key cryptography | |
CN112001713B (en) | Block chain system and request processing method and device | |
US20240303635A1 (en) | Token-based off-chain interaction authorization | |
AU2016272701A1 (en) | Systems and methods for publicly verifiable authorization | |
Wilusz et al. | The architecture of coupon-based, semi-off-line, anonymous micropayment system for Internet of Things | |
WO2021060340A1 (en) | Transaction information processing system | |
US20240078522A1 (en) | Interaction channel balancing | |
San et al. | Efficient offline micropayment protocol for multi-vendor | |
AU2022403178A1 (en) | Methods for distributed data management | |
KR20020069069A (en) | Micro payment system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20180622 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20181115 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06Q 20/38 20120101ALI20181109BHEP Ipc: G06Q 20/40 20120101ALI20181109BHEP Ipc: G06Q 30/02 20120101AFI20181109BHEP Ipc: G06Q 20/06 20120101ALI20181109BHEP |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20200518 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R003 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED |
|
18R | Application refused |
Effective date: 20220521 |