Content uploaded by Dana Love
Author content
All content in this area was uploaded by Dana Love on Mar 31, 2020
Content may be subject to copyright.
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&…
1/14
( 2 of 3 )
United States Patent Application 20200013048
Kind Code A1
Love; Dana January 9, 2020
BLOCKCHAIN-BASED SECURE PAYMENT SYSTEM
Abstract
Methods and systems for securely conducting a transaction requiring approval via a personal device of a
purchaser is provided. In some embodiments, under control of a payment application executing on the personal
device of a purchaser, the method establishes secure connection to a payment terminal of a seller. The method
receives via the secure connection transaction information generated by a point-of-sale system. The method
prompts the purchaser to approve the transaction. Upon approval, the method sends via the secure connection
with the payment terminal an indication of the approved transaction to a digital payment guardian system. Under
control of the digital payment guardian system, the method adds the approved transaction to a distributed ledger
upon receiving the approved transaction. The method settles the approved transaction and provides notification
of the settlement to the point-of-sale system so that the point-of-sale system can close the transaction.
Inventors: Love; Dana; (Phoenix, AZ)
Applicant: Name City State Country Type
Radpay, Inc. Phoenix AZ US
Family ID: 69059270
Appl. No.: 16/503177
Filed: July 3, 2019
Related U.S. Patent Documents
Application Number Filing Date Patent Number
62693864 Jul 3, 2018
Current U.S. Class: 1/1
Current CPC Class: G06Q 20/3678 20130101; G06F 16/1805 20190101; G06Q
20/204 20130101; H04L 9/3239 20130101; H04L 9/0894
20130101; H04L 2209/38 20130101; G06Q 30/0601 20130101;
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&…
2/14
H04L 9/0643 20130101; H04L 9/0637 20130101; G06Q 20/38215
20130101; H04L 2209/56 20130101
International Class: G06Q 20/36 20060101 G06Q020/36; G06Q 20/20 20060101
G06Q020/20; G06Q 30/06 20060101 G06Q030/06; G06F 16/18
20060101 G06F016/18; H04L 9/08 20060101 H04L009/08; H04L
9/06 20060101 H04L009/06; G06Q 20/38 20060101 G06Q020/38
Claims
1. A method performed by one or more computing systems for securely conducting a transaction to help prevent
fraudulent transactions, the method comprising: under control of a payment application executing on a personal
device of a purchaser, establishing a secure connection to a payment terminal of a seller; receiving via the secure
connection transaction information generated by a point-of-sale system; prompting the purchaser to approve the
transaction; upon approval, sending via the secure connection with the payment terminal an indication of the
approved transaction to a digital payment system; and under control of the digital payment system, upon
receiving the approved transaction, adding the approved transaction to a distributed ledger; settling the approved
transaction; and providing notification of settlement to the point-of-sale system.
2. The method of claim 1 wherein the settling of the transaction includes transferring a payment token to a
purchaser wallet of the purchaser.
3. The method of claim 2 wherein the payment token is underpinned with a cryptocurrency token.
4. The method of claim 2 wherein a previously issued payment token is used when settling the transaction.
5. The method of claim 1 further comprising maintaining a purchaser wallet for the purchaser that is linked to a
payment account of the purchaser.
6. The method of claim 5 wherein the settling of the transaction includes transferring a payment token to the
purchaser wallet of the purchaser.
7. The method of claim 1 wherein the establishing of the secure connection is based on exchanging public keys
of public/private key pairs.
8. The method of claim 7 wherein the establishing of the connection includes creating a symmetric key based on
the public keys.
9. A method performed by one or more computing systems for securely conducting a transaction to reduce
fraudulent transactions, the method comprising: under control of a payment application executing on a personal
device of a purchaser, establishing a secure connection to a point-of-sale terminal of a seller; receiving via the
secure connection transaction information generated by a point-of-sale system; prompting the purchaser to
approve the transaction; upon approval, sending via the secure connection with the point-of-sale terminal an
indication of the approved transaction to a digital payment system; and under control of the digital payment
system, upon receiving the approved transaction, adding the approved transaction to a distributed ledger; settling
the approved transaction; and providing notification of settlement to the point-of-sale system.
10. The method of claim 9 wherein the settling of the transaction includes transferring a payment token to a
purchaser wallet of the purchaser.
11. The method of claim 10 wherein the payment token is underpinned with a cryptocurrency token.
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&…
3/14
12. The method of claim 10 wherein a previously issued payment token is used when settling the transaction.
13. The method of claim 9 further comprising maintaining a purchaser wallet for the purchaser that is linked to a
payment account of the purchaser.
14. The method of claim 13 wherein the settling of the transaction includes transferring a payment token to the
purchaser wallet of the purchaser.
15. The method of claim 9 wherein the establishing of the secure connection is based on exchanging public keys
of public/private key pairs.
16. The method of claim 15 wherein the establishing of the connection includes creating a symmetric key based
on the public keys.
17. One or more computing systems for securely conducting a transaction to reduce risk of fraudulent
transaction, the one or more computing systems comprising: one or more computer-readable storage mediums
for storing computer-executable instructions for controlling the one or more computing systems to: under control
of a digital payment system, receive from a point-of-sale system an indication of a transaction and an identifier
of a purchaser; retrieve information on the purchaser identified by the identifier; send an approval request to a
personal device of the purchaser; and upon receiving an indication of an approval, add the approved transaction
to a distributed ledger; settle the approved transaction; and provide notification of settlement to the point-of-sale
system one or more processors for executing the computer-executable instructions stored in the one or more
computer-readable storage mediums.
18. The one or more computing systems of claim 17 wherein the instructions that settle a transaction include
instructions to calculate a transaction fee and a payment fee, allocate a cryptocurrency token corresponding to a
transaction amount, credit an account of a merchant with a cryptocurrency token corresponding to the
transaction amount less the transaction fee and payment fee, and allocate to the purchaser a payment token
corresponding to the payment fee, the payment token being underpinned by a cryptocurrency token.
19. One or more computing systems for dynamically generating payment tokens for use in reducing fraudulent
transactions, the one or more computing system comprising: one or more computer-readable storage mediums
for storing computer-executable instructions for controlling the one or more computing systems to: under control
of a payment token creation smart contract recorded in a blockchain, receive from a transaction smart contract a
buyer identifier, a transaction value, and a payment rate; receive from one or more oracles a receipt rate, an
exchange rate, and a translation rate; calculate a payment token value based on the transaction value, the receipt
rate, the exchange rate, and the translation rate; calculate a cryptocurrency token value based on the transaction
value, receipt rate, and exchange rate; store in escrow an amount of cryptocurrency tokens of the cryptocurrency
token value; and record in the blockchain a transaction representing a payment token that includes the buyer
identifier, the receipt value, the translation rate, and a status of unclaimed; and one or more processors for
executing the computer-executable instructions stored in the one or more computer-readable storage mediums.
20. The one or more computing systems of claim 19 wherein the payment token is specified as unclaimed so that
the payment token cannot be used for payment.
21. The one or more computing systems of claim 20 wherein the payment token is specified as claimed when a
claimed criterion is satisfied so that the payment token can be used for payment.
22. A method performed by one or more computing systems for dynamically generating payment tokens, the
method comprising: under control of a payment token creation smart contract recorded in a blockchain,
receiving from a transaction smart contract a buyer identifier, a transaction value, and a payment rate; receiving
from one or more oracles a receipt rate, an exchange rate and a translation rate; calculating a payment token
value based on the transaction value, the receipt rate, the exchange rate, and the translation rate; calculating a
currency token value based on the transaction value, receipt rate, and exchange rate; storing in escrow an amount
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&…
4/14
of currency tokens of the currency token value; and recording in the blockchain a transaction representing a
payment token that includes the buyer identifier, the receipt value, the translation rate, and a status of unclaimed.
23. The method of claim 22 wherein the payment token is specified as unclaimed so that the payment token
cannot be used for payment.
24. The method of claim 23 wherein the payment token is specified as claimed when a claimed criterion is
satisfied so that the payment token can be used for payment.
25. A method performed by one or more computing systems for securely conduction a transaction to reduce risk
of a fraudulent transaction, the method comprising: receiving from an e-commerce site an indication of a
transaction and information relating to a purchaser; upon determining that the purchaser has an account with a
digital payment system, sending to a personal device of the purchaser an indication of the transaction; receiving
from the personal device of the purchaser an indication that the purchaser has approved the transaction; settling
the transaction using a financial account linked to the account of the purchaser; and notifying the e-commerce
site that the transaction has been settled.
26. The method of claim 25 wherein upon determining that the purchaser does not have an account with the
digital payment system, creating an account for the purchaser that is linked to a financial account identified in
the information relating to the purchaser.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional Patent Application No. 62/693,864, filed Jul. 3,
2018, titled A BLOCKCHAIN-BASED SECURE PAYMENT SYSTEM, which is incorporated herein by
reference in its entirety.
BACKGROUND
[0002] The bitcoin system was developed to allow electronic cash to be transferred directly from one party to
another without going through a financial institution, as described in the white paper entitled "Bitcoin: A Peer-
to-Peer Electronic Cash System" by Satoshi Nakamoto. A bitcoin (e.g., an electronic coin) is represented by a
chain of transactions that transfers ownership from one party to another party. To transfer ownership of a bitcoin,
a new transaction is generated and added to a stack of transactions in a block. The new transaction, which
includes the public key of the new owner, is digitally signed by the owner with the owner's private key to
transfer ownership to the new owner, as represented by the new owner public key. The signing by the owner of
the bitcoin is an authorization by the owner to transfer ownership of the bitcoin to the new owner via the new
transaction. Once the block is full, the block is "capped" with a block header that is a hash digest of all the
transaction identifiers within the block. The block header is recorded as the first transaction in the next block in
the chain, creating a mathematical hierarchy called a "blockchain." To verify the current owner, the blockchain
of transactions can be followed to verify each transaction from the first transaction to the last transaction. The
new owner need only have the private key that matches the public key of the transaction that transferred the
bitcoin. The blockchain creates a mathematical proof of ownership in an entity represented by a security identity
(e.g., a public key), which in the case of the bitcoin system is pseudo-anonymous.
[0003] To ensure that a previous owner of a bitcoin did not double-spend the bitcoin (i.e., transfer ownership of
the same bitcoin to two parties), the bitcoin system maintains a distributed ledger of transactions. With the
distributed ledger, a ledger of all the transactions for a bitcoin is stored redundantly at multiple nodes (i.e.,
computers) of a blockchain network. The ledger at each node is stored as a blockchain. In a blockchain, the
transactions are stored in the order that the transactions are received by the nodes. Each node in the blockchain
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&…
5/14
network has a complete replica of the entire blockchain. The bitcoin system also implements techniques to
ensure that each node will store the identical blockchain, even though nodes may receive transactions in
different orderings. To verify that the transactions in a ledger stored at a node are correct, the blocks in the
blockchain can be accessed from oldest to newest, generating a new hash of the block and comparing the new
hash to the hash generated when the block was created. If the hashes are the same, then the transactions in the
block are verified. The bitcoin system also implements techniques to ensure that it would be infeasible to change
a transaction and regenerate the blockchain by employing a computationally expensive technique to generate a
nonce that is added to the block when it is created. A bitcoin ledger is sometimes referred to as an Unspent
Transaction Output ("UTXO") set because it tracks the output of all transactions that have not yet been spent.
[0004] Although the bitcoin system has been very successful, it is limited to transactions in bitcoins or other
cryptocurrencies. Efforts are currently underway to use blockchains to support transactions of any type, such as
those relating to the sale of vehicles, sale of financial derivatives, sale of stock, payments on contracts, and so
on. Such transactions use identity tokens, which are also referred to as digital bearer bonds, to uniquely identify
something that can be owned or can own other things. An identity token for a physical or digital asset is
generated using a cryptographic one-way hash of information that uniquely identifies the asset. Tokens also have
an owner that uses an additional public/private key pair. The owner public key is set as the token owner identity,
and when performing actions against tokens, ownership proof is established by providing a signature generated
by the owner private key and validated against the public key listed as the owner of the token. A person can be
uniquely identified, for example, using a combination of a user name, social security number, and biometric
(e.g., fingerprint). A product (e.g., refrigerator) can be uniquely identified, for example, using the name of its
manufacturer and its serial number. The identity tokens for each would be a cryptographic one-way hash of such
combinations. The identity token for an entity (e.g., person or company) may be the public key of a
public/private key pair, where the private key is held by the entity. Identity tokens can be used to identify people,
institutions, commodities, contracts, computer code, equities, derivatives, bonds, insurance, loans, documents,
and so on. Identity tokens can also be used to identify collections of assets. An identity token for a collection
may be a cryptographic one-way hash of the digital tokens of the assets in the collection. The creation of an
identity token for an asset in a blockchain establishes provenance of the asset, and the identity token can be used
in transactions (e.g., buying, selling, insuring) involving the asset stored in a blockchain, creating a full audit
trail of the transactions.
[0005] To record a simple transaction in a blockchain, each party and asset involved with the transaction needs
an account that is identified by a digital token. For example, when one person wants to transfer a car to another
person, the current owner and next owner create accounts, and the current owner also creates an account that is
uniquely identified by the car's vehicle identification number. The account for the car identifies the current
owner. The current owner creates a transaction against the account for the car that indicates that the transaction
is a transfer of ownership, indicates the public keys (i.e., identity tokens) of the current owner and the next
owner, and indicates the identity token of the car. The transaction is signed by the private key of the current
owner, and the transaction is evidence that the next owner is now the current owner.
[0006] To enable more complex transactions than bitcoin can support, some systems use "smart contracts." A
smart contract is computer code that implements transactions of a contract. The computer code may be executed
in a secure platform (e.g., an Ethereum platform, which provides a virtual machine) that supports recording
transactions in blockchains. In addition, the smart contract itself is recorded as a transaction in the blockchain
using an identity token that is a hash (i.e., identity token) of the computer code so that the computer code that is
executed can be authenticated. When deployed, a constructor of the smart contract executes, initializing the
smart contract and its state. The state of a smart contract is stored persistently in the blockchain. When a
transaction is recorded against a smart contract, a message is sent to the smart contract, and the computer code of
the smart contract executes to implement the transaction (e.g., debit a certain amount from the balance of an
account). The computer code ensures that all the terms of the contract are complied with before the transaction is
recorded in the blockchain. For example, a smart contract may support the sale of an asset. The inputs to a smart
contract to sell a car may be the identity tokens of the seller, the buyer, and the car and the sale price in U.S.
dollars. The computer code ensures that the seller is the current owner of the car and that the buyer has sufficient
funds in their account. The computer code then records a transaction that transfers the ownership of the car to
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&…
6/14
the buyer and a transaction that transfers the sale price from the buyer's account to the seller's account. If the
seller's account is in U.S. dollars and the buyer's account is in Canadian dollars, the computer code may retrieve
a currency exchange rate, determine how many Canadian dollars the seller's account should be debited, and
record the exchange rate. If either transaction is not successful, neither transaction is recorded.
[0007] When a message is sent to a smart contract to record a transaction, the message is sent to each node that
maintains a replica of the blockchain. Each node executes the computer code of the smart contract to implement
the transaction. For example, if 100 nodes each maintain a replica of a blockchain, then the computer code
executes at each of the 100 nodes. When a node completes execution of the computer code, the result of the
transaction is recorded in the blockchain. The nodes employ a consensus algorithm to decide which transactions
to keep and which transactions to discard. Although the execution of the computer code at each node helps
ensure the authenticity of the blockchain, it requires large amounts of computer resources to support such
redundant execution of computer code.
[0008] Purchase transactions between retailers (or merchants) and purchasers (or customers) are typically paid
for with credit cards. Credit card purchases, however, are particularly vulnerable to fraud. Any person with
access to credit card (e.g., a stolen credit card) for in-store purchases or credit card information (e.g., purchased
on the web) for online purchases can make a purchase without the approval of the credit card holder. Although
consumer protection laws may provide some degree of protection for the credit card holder (assuming the fraud
is noticed), the credit card company may be liable for the fraudulent purchase. To help prevent such fraudulent
purchases, a credit card company may employ extensive fraud protection mechanism. For example, if a purchase
is made at a retailer in a geographic area in which the credit card holder does not normally use the credit card
(e.g., a different country), the credit card company may put a fraud alert on the account and decline the purchase
transaction. To remove a fraud alert, a credit card holder may need to contact the credit card company, provide
the necessary credentials, prove that the transaction is not fraudulent, and again attempt to make the purchase.
The time needed to remove the fraud alert can present problems for various types of purchases such as a
purchase for a ticket on a train or plane that is about to depart, for a toll road, and so on.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIG. 1 is a flow diagram that illustrates the processing of a transaction smart contract of the secure
payment system in some embodiments.
[0010] FIG. 2 is a flow diagram that illustrates the processing of a RT creation smart contract of the secure
payment system in some embodiments.
[0011] FIG. 3 illustrates a methodology in which a payment terminal has a wireless capability.
[0012] FIG. 4 illustrates a methodology in which a payment terminal and/or POS terminal has a wireless
capability.
[0013] FIG. 5 illustrates a methodology in which no payment terminal is available and the POS terminal does
not have wireless capability.
[0014] FIG. 6 illustrates a methodology in which neither the payment terminal nor the POS terminal has wireless
capability.
[0015] FIG. 7 illustrates a methodology in which neither the payment terminal noted POS terminal have SPN
capabilities.
[0016] FIG. 8 illustrates methodologies for employing SPN capabilities at an e-commerce web site.
[0017] FIG. 9 is a flow diagram that illustrates the processing of a transaction smart contract of the secure
payment system in some embodiments.
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&…
7/14
[0018] FIG. 10 is a flow diagram that illustrates the processing of a PT creation smart contract of the secure
payment system in some embodiments.
DETAILED DESCRIPTION
[0019] A secure payment network system is provided that support an infrastructure for smart contracts to
enforce merchant settlements with associated consumer payment methodologies. In some embodiments, the
framework of the secure payment network ("SPN") system provides scalable support for a high number
(potentially tens of millions) of transactions per second using blockchain technology such as Plasma on
Ethereum blockchain. The SPN system allows for consumers to make secure payments at retail establishments
(including physical and online) using cryptocurrency wallets and cryptocurrencies with the aid of consumer
(purchaser) personal devices (e.g., smartphones). The SPN network system provides a common infrastructure for
interfacing personal devices, payment terminals (e.g., credit/debit card terminals), point-of-sale ("POS")
terminals, and a digital payment guardian ("DPG") system of the SPN system that supports a variety of payment
methodologies. In addition, to ensuring security, the SPN system enforces a user approval mechanism through
which transactions require approval using the personal devices of the purchasers. Thus, even if a purchaser's
credit card information is stolen, transactions using that credit card information will be denied because the
fraudulent purchaser will not have access to the purchaser's personal device to provide the approval. The SPN
system supports secure transmission of approval information using various encryption techniques such as
asymmetric encryption (e.g., private/public keypair encryption) and/or symmetric encryption (e.g., Diffie-
Hellman key exchange). To help reduce the risk of fraudulent purchases to retailers and/or purchasers, the SPN
system may allocate payment network tokens ("PTs") to purchasers as part of a purchase transactions handled
through the payment network system. The PTs may be used to pay for purchases using the SPN system. In this
way, purchasers have an incentive to purchase from retailers who support secure transactions using the SPN
system. Because of the efficiencies and security provided by the SPN system, transaction fees associated with
conventional payment methodologies can be avoided or reduced and the cash positions of retailers is improved.
Also, liability of a credit card company for fraudulent purchases can be reduced.
[0020] In some embodiments, the SPN system employs wireless technology to support communications between
personal devices, payment terminals, POS terminals, and the DPG system. During the checkout process,
depending the payment methodology supported by the retailer, the payment terminal, the POS terminal, or the
DPG system pushes via a secure communications channel information describing the transaction to a purchaser
payment application of the SPN system installed on the personal device of the purchaser. The secure
communications channel may be established by the purchaser payment application exchanging public keys of a
public/private keypair. Messages sent via the secure communications channel may be encrypted with the
recipient's public key and decrypted with the recipient's private key or the public keys may be used to establish a
symmetric key for encrypting and decrypting messages. The payment application displays information
describing the transaction to the purchaser and prompts the purchase to approve or decline. When the purchaser
approves, the payment application sends an approval notification to the payment terminal, the POS terminal, or
the DPG system again depending on the payment methodology supported by the retailer. The payment terminals
and the POS terminals may also have payment applications of the SPN system for coordinating the processing of
payments via the SPN system. The DPG system eventually receives an indication of the approved transaction
and settles the transaction by recording transaction information in a blockchain (or more generally distributed
ledger), debiting an account of the purchaser, crediting an account of the retailer, and issuing PTs.
[0021] In some embodiments, to participate in the SPN, a purchaser establishes a purchaser wallet with the SPN
system. A purchaser wallet may be linked to an underlying account (e.g., bank account) of the purchaser and
store credentials (e.g., private key) for access to PTs of the purchaser. The PTs may be allocated to the purchaser
during a transaction, transferred to the purchaser from another purchaser (e.g., charitable contribution), or
purchased by the purchaser. The DPG system may have a DPG wallet that stores credentials for cryptocurrency
tokens ("CT") used to underpin the PTs. The cryptocurrency tokens (e.g., EIP20 tokens) can be purchased and
sold on an exchange (e.g., Bittrex and Coinbase) using fiat currency. The DPG system may maintain an
allocation of reserve CTs in the DPG wallet or may purchase or mint CTs on demand. A retailer who participates
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&…
8/14
in the SPN may have a retailer wallet that may be linked to an underlying account. A retailer wallet may only be
used to store CTs corresponding the net transaction value while a transaction is being settled. As part of the
settlement, the DPG system may direct that the CTs of the retailer wallet be exchanged for fiat currency, which
is then deposited in the linked account of the retailer.
[0022] In some embodiments, when the DPG system receives the indication of an approved transaction (i.e.,
approved using a personal device of a purchaser), the DPG system settles the transaction. To settle the
transaction, the DPG system may debit the transaction amount of fiat currency from the purchaser wallet of the
purchaser. The DPG system may then exchange the transaction amount for CTs (e.g., from the reserve of CTs or
newly purchased CTs) and hold the CTs in escrow for settlement of the transaction. The DPG system then
calculates a transaction fee and a PT fee in cryptocurrency for the transaction. The DPG system then mints PTs
corresponding to the PT fee and links the PTs to an equivalent amount of CTs held in escrow. The PTs are
referred to as the underpinned tokens, and the CTs are referred to as the underpinning tokens. The DPG system
transfers the PTs to the purchaser wallet of the purchaser. The DPG system also transfers a net transaction
amount (e.g., transaction amount minus fees) of CTs from escrow to the retailer wallet of the retailer and then,
depending on preference of the retailer, may automatically exchange the CTs for fiat currency and credits the
account linked to the retailer wallet of the retailer. The DPG system then transfers the CTs remaining in escrow
(i.e., a transaction fee amount) to the DPG wallet. The DPG system may store the transaction in the blockchain
when it receives the approval. Alternatively, the purchaser application, payment terminal application, or POS
terminal application may store the transaction in the blockchain, and the DPG system may store update
transactions such as transactions to transfer PTs and CTs, to mark the transactions as settled, and so on.
[0023] As mentioned above, the SPN system provides a PT that is tied to an underpinning cryptocurrency. The
PT establishes a store of value for the CT underpinning the PT, which can be used as a medium of exchange with
transactions. The CT is established as a unit of account as each transaction on the SPN is tied to the value of
local fiat currency, and each PT is simultaneously linked to that local fiat currency and to a measure of the CT.
As such, a PT and CT pair represent a secure digital currency.
[0024] In some embodiments, the CT (i.e., underpinning cryptocurrency token) may be an EIP20 compatible
token on the Ethereum blockchain. A CT may be required for access to the SPN, such that participation in the
SPN is established through the presence of a certain threshold of CTs in the wallets of participants (e.g.,
retailers) in the SPN. The CTs provide virtual crypto "fuel" for using certain designated functions on the SPN
such as executing transactions and running distributed applications that interface with the SPN system.
[0025] In some embodiments, the PT may be as an EIP20 token on the Ethereum blockchain. The SPN system
mints PTs when processing a transaction. The underpinning cryptocurrency (i.e., CT) of the PT is funded
through a portion of the fee generated through settlement. The CTs are delivered to the purchasers (e.g.,
recording a transfer transaction in the blockchain) originating a transaction. The CTs are both tied to value of fiat
currency at the time of minting (which provides short-term stability to the token) and underpinned by the CT
(which provides longer-term store of value).
[0026] In some embodiment, a transaction is processed by the SPN system as illustrated by the following
example. A purchaser initiates a transaction with a retailer such as the purchase of a toy for $83.20. At the time
of the transaction, ETH (i.e., Ethereum cryptocurrency) is valued $522.51, a CT is valued at 0.00125 ETH, and a
PT is valued at 0.001 CT; the PT fee is 1.00%, and the transaction fee is 0.75%. During settlement of the
transaction, a smart contract associated with the transaction debits $83.20 from the purchaser wallet of the
purchaser (e.g., debiting the linked account or transferring PTs held in the purchaser wallet). The smart contract
may supply the transaction amount to an oracle that returns the transaction fee of $0.6240 (i.e., $83.20*0.75%) is
deducted from the transaction amount and credited to the DPG wallet. The oracle (or a different oracle) may also
return a payment fee $0.8320 (i.e., $83.20*1.00%). The smart contract may deposit $81.744 (i.e.,
$83.20-$0.6240-$0.8320) in the retailer wallet. An oracle may also return a 1.274 CT value (i.e.,
$0.8320/($522.51*0.00125)). The smart contract then mints a PT with a value of 1,274.00 (i.e., 1.274 CT/0.001
PTs per CT) and transfers the PT to the purchaser wallet. In some embodiments, the smart contact may interact
with a trust oracle which provides an indication of trustworthiness of the purchaser. For example, if a person
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&…
9/14
reports that their smartphone is missing, the trustworthiness score may be low for purchases using that
smartphone to conduct a transaction. The DPG system may decline transactions in part based on trustworthiness.
[0027] In some embodiments, a PT creation smart contract may dynamically create a number of PTs that are
underpinned by CTs. A certain number of CTs may be minted in a single event (e.g., an ICO) or following a
programmatic mathematical process of minting (e.g., mining). In contrast, the PTs are minted dynamically to
meet demand. The PT creation smart contract is used to create the PTs and is invoked when the transaction smart
contract invokes the PT creation smart contract (e.g., recording a message transaction) in a secure and trusted
manner. A series of oracles are used to gather the various data points for the smart contract to successfully
complete its task. A transaction smart contract serves as oracle for a number of data elements and provides them
to the PT creation smart contract: [0028] 1.) Purchaser ID ("PID"); [0029] 2.) TransactionValue (the verified
purchase amount); [0030] 3.) Currency used for transaction (e.g., USD); and [0031] 4.) Payment Fee Rate. The
DPG system provides the following oracles to the PT creation smart contract: [0032] 1.) ExchangeRateXXX
oracle, the value of the underpinning cryptocurrency on open market, in the currency used for transaction, where
XXX is the three-letter code for the CryptoType; [0033] 2.) CryptoType oracle, the type of cryptocurrency to be
used for underpinning purposes; and [0034] 3.) TranslationRate oracle, which establishes the ratio of
cryptocurrency to token for this transaction.
[0035] The PT creation smart contract draws the underpinning cryptocurrency, CT, in the amount of the
transaction value (the purchase amount) multiplied by the payment fee rate. The PT creation smart contract may
buy CTs from an exchange, from a purchaser or retailer, or from the SPN system.
[0036] The PT creation smart contract then determines the amount of underpinned tokens PTs to create and the
underpinning cryptocurrency CT to acquire. This may be determined as follows:
T.sub.payment=TransactionValueValid*PaymentRate/ExchangeRateXXX*Translat- ionRate
And
C.sub.underpin=for Crypto Type, TransactionValueValid*PaymentRate/ExchangeRateXXX
The PT creation smart contract places Cunderpin (the underpinning cryptocurrency) in a smart contract escrow
and records to the blockchain the following elements: [0037] 1.) UserID of Buyer; [0038] 2.) T.sub.payment, the
number of PTs in escrow; [0039] 3.) TranslationRate, the ratio from PT to CT; and [0040] 4.) ClaimStatus is set
to Unclaimed. ClaimStatus is a state variable designed such that tokens escrowed by the PT creation smart
contract which are underpinned by CTs escrowed for such underpinning are not automatically allocated, but
rather are allocated after a claim process.
[0041] Once the PT is created, it is placed in escrow for claim by the purchaser, and a blockchain transactions is
recorded noting the value of the PT and the hashed UserlD connected to the PTs, and the ClaimStatus state
variable is created as Unclaimed. In some embodiments, the PTs may be automatically recorded as claimed or
held unclaimed until a certain criterion is meet such as the purchaser participating in a threshold number of
transactions.
[0042] FIG. 1 is a block diagram that illustrates entities participating in the SPN. The SPN system includes a
DPG system 101 that interfaces with personal devices 102, payment terminals 103, POS terminals 104, and
credit card systems 105. The personal devices, payment terminals, POS terminals, and credit card systems may
include payment applications that are part of the SPN system. The SPN system records various transactions in a
blockchain 106. The transactions relate to purchase transactions, PT creation transactions, CT creation
transactions, and so on.
[0043] FIG. 2 is a flow diagram that illustrates the overall processing of settlements by the DPG system in some
embodiments. A settlement component 200 is invoked passing an indication of an approved transaction that is to
be settled. In decision block 201, if the transaction is already stored in the blockchain, then the component
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND…
10/14
continues at block 203, else the component continues at block 202. In block 202, the component records in the
blockchain a transaction record with details of the transaction such as transaction amount, product category,
purchaser identifier, retailer identifier, and so on. In block 203, the component transfers a transaction amount of
fiat currency from the purchaser wallet to a DPG wallet. In block 204, the component transfers the transaction
amount of CTs to an escrow. In block 205, the component retrieves the PT rate (or payment rate), transaction
rate, and CT and PT valuations. In block 206, the component calculates the transaction fee. In block 207, the
component calculates the PT fee. In block 208, the component calculates the transaction net amount, which is
the amount to be paid to the retailer. In block 209, the component exchanges the transaction net amount to a
transaction net fiat amount based on the valuations. In block 210, the component transfers the transaction net fiat
amount to the retailer wallet. The component may alternatively allocate CTs to the retailer wallet and the convert
the CTs to fiat currency. In block 211, the component creates a PT that is underpinned by a PT fee amount of
CTs. In block 212, the component transfers the PT to the purchaser's wallet. In block 213, the component
transfers the transaction fee from escrow to the DPG wallet and completes.
[0044] FIGS. 3-8 illustrate different methodologies for conducting transactions with the SPN system. The
figures illustrate the interaction between a personal device of a purchaser, a payment terminal, a POS terminal,
and the DPG system. These methodologies allow the SPN system to dynamically adapt to the differences in
capabilities of the personal devices, payment terminals, POS terminals, credit card services, and e-commerce
sites. The capabilities include wireless capabilities, SPN compatible capabilities, and so on.
[0045] FIG. 3 illustrates a methodology in which a payment terminal has a wireless capability. Initially, POS
terminal 330 generates 331 a transaction that includes transaction amount, product identifier, and retailer
identifier. The POS terminal provides the transaction amount to the payment terminal 320. The payment terminal
displays 321 the transaction amount to the purchaser. The personal device 310 then establishes 311 a secure
connection with the payment terminal. The payment terminal sends 322 transaction information to the personal
device. The personal device displays 312 a request for approval and sends an indication of the approval to the
payment terminal. Upon receiving the approval, the payment terminal forwards 323 the approved transaction to
the DPG system 340. The DPG system 340, upon receiving the transaction, records 341 a transaction in the
blockchain. The DPG system then invokes 342 the settlement component to settle the transaction. The DPG
system then notifies the POS terminal that the transaction has been settled. The POS terminal then closes 332 the
sale and completes. Alternatively, the DPG system may notify the payment terminal that the transaction has
settled and the payment terminal and then notify the POS terminal that the transaction has settled. In such a case,
the POS terminal may not have a SPN application.
[0046] FIG. 4 illustrates a methodology in which a payment terminal and/or POS terminal has a wireless
capability. With this methodology, the payment terminal may not have an SPN application and may operate only
as a pass-through (e.g., indicated by dashed lines) to the personal device when the POS terminal does not have a
wireless capability. Initially, the personal device 410 and the payment terminal 420 and/or POS terminal 430
establish 411, 421, and 431 a secure connection. The POS terminal generates 432 a transaction and sends the
transaction to the personal device. The personal device displays 412 an approval request and sends an indication
the approval to the POS terminal. The POS terminal forwards 433 the approved transaction to the DPG system
440. The DPG system adds 441 a transaction to the blockchain. In block 442, the DPG system invokes 442 a
settlement component to settle the transaction and notifies the POS terminal of the settlement. The POS terminal
then closes 434 the sale and completes.
[0047] FIG. 5 illustrates a methodology in which no payment terminal is available and the POS terminal does
not have wireless capability. Initially, the POS terminal 530 generates 531 the transaction. The POS terminal
receives 532 a purchaser identifier such as an email address or phone number that may be provided by the
purchaser. The POS terminal then sends the transaction and the purchaser identifier to the DPG system 540. The
DPG system retrieves 541 information about the purchaser and verifies their status as a participant in the SPN.
The DPG system then notifies the personal device 510 of the transaction. The personal device displays 511 an
approval request for the transaction and sends an indication the approval to the DPG system. Upon receiving the
approval, the DPG system records 542 the transaction in the blockchain. The DPG system then invokes 543 the
settlement component to settle the transaction. The DPG system then notifies the POS terminal of the settlement.
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND…
11/14
The POS terminal then closes 533 the sale and then completes.
[0048] FIG. 6 illustrates a methodology in which neither the payment terminal nor the POS terminal has wireless
capability. The POS terminal 630 generates 631 the transaction and notifies the payment terminal 620 of the
transaction. The payment terminal displays 621 transaction information to the purchaser. The payment terminal
then receives 622 credit card information from the credit card of the purchaser. The payment terminal sends
transaction and credit card information to the DPG system. The DPG system 640 retrieves 641 the identifier of
the purchaser and verifies that they are authorized to use the SPN. The DPG system then provides the transaction
to the personal device 610. The personal device 610 displays 611 an approval request and sends an indication the
approval to the DPG system. The DPG system adds 642 the transaction to the blockchain. The DPG system
invokes 643 the settlement component to settle the transaction and notifies the POS terminal of the settlement.
The POS terminal then closes 632 the sale and completes.
[0049] FIG. 7 illustrates a methodology in which neither the payment terminal nor the POS terminal has SPN
capabilities. The POS terminal 730 generates 731 the purchase transaction and forwards it to the payment
terminal 720. The payment terminal displays 721 the transaction to the purchaser. The payment terminal then
receives 722 credit card information from the credit card of the purchaser. The payment terminal then forwards
the transaction and credit card information to the credit card system 750 (e.g., Visa processing system). The
credit card system validates 751 the transaction and credit card and forwards an approval request to the DPG
system 740. The DPG system retrieves 741 the purchaser identifier and forwards the transaction to the personal
device 710 of the purchaser. The personal device displays 711 an approval request and sends an indication the
approval to the DPG system. The DPG system adds 742 a transaction to the blockchain and sends an approval
notification to the credit card system. The credit card system then settles 752 the transaction and notifies the
POS terminal. The POS terminal closes 732 the sale and completes.
[0050] FIG. 8 illustrates methodologies for employing SPN capabilities at an e-commerce web site. A purchaser
at an e-commerce site 860 designates items to be purchased, and the e-commerce site displays 861 shopping cart
information for the purchase transaction. The purchaser may decide to checkout as a guest or use an existing
account at the e-commerce site. If the purchaser selects a guest checkout, the e-commerce site collects 864 credit
card information from the purchaser and sends the transaction and credit card information to the DPG system
840. If the purchaser selects an account checkout, the e-commerce site retrieves 863 account information and
sends the transaction and an identifier of the purchaser to the DPG system. If the purchaser does not have an
account with the SPN system, the DPG system creates 842 an account and notifies the e-commerce site that an
account has been created. Although not illustrated, the e-commerce site may solicit approval of the purchaser to
create a purchaser wallet (an account) with the SPN system. The e-commerce site then displays 865 an approval
request for the transaction and sends an indication of the approval to the DPG system. If the purchaser does have
an account with the SPN system, the DPG system retrieves 843 account information and sends the transaction to
the personal device 810 of the purchaser. The personal device displays 811 an approval request and sends an
indication of the approval to the DPG system. Upon receiving an indication that the purchaser has approved the
transaction either via the e-commerce site or the personal device, the the DPG system adds 844 a transaction to
the blockchain. The DPG system then settles 845 the transaction and notifies the e-commerce site. The e-
commerce site closes 866 the sale and completes. In some embodiments, the SPN system may support creating
of an account with the SPN system when a customer creates an account with an e-commerce site irrespective of
whether the customer is making a purchase. In a case, the processing of steps 864, 841, and 842 would be used
to create the account that includes the purchaser wallet. When the customer subsequently makes a purchase, the
processing of step 861, 862, 863, 841, 843, 811, 844, 845, and 866 would be used to settle the transaction.
[0051] FIG. 9 is a flow diagram that illustrates the processing of a transaction smart contract of the secure
payment system in some embodiments. A transaction smart contract component executes to coordinate the
processing of a transaction. In block 901, the component confirms agreement of the parties to the transaction.
The parties include a buyer ("B") and one or more sellers ("S"). In block 902, the component retrieves a
transaction value ("TxnValue") from an oracle provided by the seller that provides pricing information. In block
903, the component retrieves the current balance from the buyer's wallet. In block 904, the component retrieves
payment rate and transaction fee information from an oracle provided by ecosystem. In block 905, the
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND…
12/14
component retrieves a trust factor for the buyer. The trust factor may be generated by a trust factor smart
contract that analyzes transactions to determine the trustworthiness of a buyer. In decision block 906, if the
buyer satisfies a trust criterion then the component continues at block 907, else the component performs error
processing. The trust criterion may be based on, for example, a combination of the trust factor and the
transaction value. In block 907, the component debits the buyer's wallet by the transaction value. In block 908,
the component sends to an RT creation smart contract an identifier of the buyer, the transaction value, the
payment rate, and the currency that the transaction is in (e.g., US dollars). In block 909, the component credits
the operator of the secure payment system with the transaction fee. In block 910, the component credits the
seller with the transaction value minus the transaction fee and the value of the PT. The component then
completes.
[0052] FIG. 10 is a flow diagram that illustrates the processing of a PT creation smart contract of the secure
payment system in some embodiments. The PT creation smart contract component 1000 executes to create a PT.
In block 1001, the component receives a buyer identifier, a transaction value, a payment rate, and the currency
type. In block 1002, the component retrieves the current exchange rate, the type of the currency token, and a
translation rate. In block 1003, the component calculates the amount of PTs as the award and the corresponding
value of the CT. In block 1004, the component stores the value of the CT in escrow. In block 1005, the
component records a transaction in the blockchain with the buyer identifier, the amount of the PT, the translation
rate and the current status as the payment being unclaimed. The component then completes.
[0053] The computing systems (e.g., network nodes or collections of network nodes) on which the secure
payment system may be implemented may include a central processing unit, input devices, output devices (e.g.,
display devices and speakers), storage devices (e.g., memory and disk drives), network interfaces, graphics
processing units, cellular radio link interfaces, global positioning system devices, and so on. The input devices
may include keyboards, pointing devices, touch screens, gesture recognition devices (e.g., for air gestures), head
and eye tracking devices, microphones for voice recognition, and so on. The computing systems may include
desktop computers, laptops, tablets, e-readers, personal digital assistants, smartphones, gaming devices, servers,
and so on. The computing systems may access computer-readable media that include computer-readable storage
media and data transmission media. The computer-readable storage media are tangible storage means that do not
include a transitory, propagating signal. Examples of computer-readable storage media include memory such as
primary memory, cache memory, and secondary memory (e.g., DVD) and other storage. The computer-readable
storage media may have recorded on them or may be encoded with computer-executable instructions or logic
that implements the secure payment system. The data transmission media are used for transmitting data via
transitory, propagating signals or carrier waves (e.g., electromagnetism) via a wired or wireless connection. The
computing systems may include a secure cryptoprocessor as part of a central processing unit for generating and
securely storing keys and for encrypting and decrypting data using the keys.
[0054] The secure payment system may be described in the general context of computer-executable instructions,
such as program modules and components, executed by one or more computers, processors, or other devices.
Generally, program modules or components include routines, programs, objects, data structures, and so on that
perform tasks or implement data types of the BPQS system. Typically, the functionality of the program modules
may be combined or distributed as desired in various examples. Aspects of the secure payment system may be
implemented in hardware using, for example, an application-specific integrated circuit ("ASIC") or field
programmable gate array ("FPGA").
[0055] The following paragraphs describe various embodiments of aspects of the SPN system. Implementations
of the system may employ any combination of the embodiments and aspects of the embodiments. The
processing described below may be performed by a computing system with a processor that executes computer-
executable instructions stored on a computer-readable storage medium that implements the system.
[0056] In some embodiments, a method performed by one or more computing systems is provided for securely
conducting a transaction to help prevent fraudulent transactions. Under control of a payment application
executing on a personal device of a purchaser, the method establishes a secure connection to a payment terminal
of a seller. The method receives via the secure connection transaction information generated by a point-of-sale
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND…
13/14
system. The method prompts the purchaser to approve the transaction. Upon approval, the method sends via the
secure connection with the payment terminal an indication of the approved transaction to a digital payment
system. Under control of the digital payment system, upon receiving the approved transaction, the method adds,
he approved transaction to a distributed ledger, settles the approved transaction, and provides notification of the
settlement to the point-of-sale system. In some embodiments, the settling of the transaction includes transferring
a payment token to a purchaser wallet of the purchaser. In some embodiments, the payment token is underpinned
with a cryptocurrency token. In some embodiments, a previously issued payment token is used when settling the
transaction. In some embodiments, the method further maintains a purchaser wallet for the purchaser that is
linked to a payment (financial) account of the purchaser. In some embodiments, the settling of the transaction
includes transferring a payment token to the purchaser wallet of the purchaser. In some embodiments, the
establishing of the secure connection is based on exchanging public keys of public/private key pairs. In some
embodiments, the establishing of the connection includes creating a symmetric key based on the public keys.
[0057] In some embodiments, a method performed by one or more computing systems is provided for securely
conducting a transaction to reduce fraud. Under control of a payment application executing on a personal device
of a purchaser, the method establishes a secure connection to a point-of-sale terminal of a seller. The method
receives via the secure connection transaction information generated by a point-of-sale system. The method
prompts the purchaser to approve the transaction. Upon approval, the method sends via the secure connection
with the point-of-sale terminal an indication of the approved transaction to a digital payment system. Under
control of the digital payment system, upon receiving the approved transaction, the method adds the approved
transaction to a distributed ledger, settles the approved transaction, and provides notification of the settlement to
the point-of-sale system. In some embodiments, the settling of the transaction includes transferring a payment
token to a purchaser wallet of the purchaser. In some embodiments, the payment token is underpinned with a
cryptocurrency token. In some embodiments, a previously issued payment token is used when settling the
transaction. In some embodiments, the method further maintains a purchaser wallet for the purchaser that is
linked to a payment account of the purchaser. In some embodiments, the settling of the transaction includes
transferring a payment token to the purchaser wallet of the purchaser. In some embodiments, the establishing of
the secure connection is based on exchanging public keys of public/private key pairs. In some embodiments, the
establishing of the connection includes creating a symmetric key based on the public keys.
[0058] In some embodiments, one or more computing systems are provided for securely conducting a
transaction to reduce risk of fraudulent transaction, the one or more computing systems comprise one or more
computer-readable storage mediums for storing computer-executable instructions for controlling the one or more
computing systems and one or more processors for executing the computer-executable instructions stored in the
one or more computer-readable storage mediums. The instructions of digital payment system receive from a
point-of-sale system an indication of a transaction and an identifier of a purchaser, retrieve information on the
purchaser identified by the identifier, send an approval request to a personal device of the purchaser, and upon
receiving an indication of the approval, add the approved transaction to a distributed ledger, settle the approved
transaction, and provide notification of the settlement to the point-of-sale system In some embodiments, the
instructions that settle a transaction include instructions to calculate a transaction fee and a payment fee, allocate
a cryptocurrency token corresponding to a transaction amount, credit an account of a merchant with a
cryptocurrency token corresponding to the transaction amount less the transaction fee and payment fee, and
allocate a payment token to the purchases corresponding to the payment fee, the payment token being
underpinned by a cryptocurrency token.
[0059] In some embodiments, one or more computing systems are provided for dynamically generating payment
tokens for use in reducing fraudulent transactions. The one or more computing system comprise one or more
computer-readable storage mediums for storing computer-executable instructions for controlling the one or more
computing systems and one or more processors for executing the computer-executable instructions stored in the
one or more computer-readable storage mediums. Under control of a payment token creation smart contract
recorded in a blockchain, the instructions receive from a transaction smart contract a buyer identifier, a
transaction value, and a payment rate. The instructions receive from one or more oracles an exchange rate and a
translation rate. The instructions calculate a payment token value based on the transaction value, the receipt rate,
the exchange rate, and the translation rate. The instructions calculate a cryptocurrency token value based on the
3/31/2020 United States Patent Application: 0200013048
appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND…
14/14
transaction value, receipt rate, and exchange rate. The instructions store in escrow an amount of cryptocurrency
tokens of the cryptocurrency token value. The instructions record in the blockchain a transaction representing a
payment token that includes the buyer identifier, the receipt value, the translation rate, and a status of unclaimed.
In some embodiments, the payment token is specified as unclaimed so that the payment token cannot be used for
payment. In some embodiments, the payment token is specified as claimed when a claimed criterion is satisfied
so that the payment token can be used for payment.
[0060] In some embodiments, a method performed by one or more computing systems is provided for
dynamically generating payment tokens. The method under control of a payment token creation smart contract
recorded in a blockchain, receives from a transaction smart contract a buyer identifier, a transaction value, and a
payment rate. The method receives from one or more oracles an exchange rate and a translation rate. The
method calculates a payment token value based on the transaction value, the receipt rate, the exchange rate, and
the translation rate. The method calculates a currency token value based on the transaction value, receipt rate,
and exchange rate. The method stores in escrow an amount of currency tokens of the currency token value. The
method records in the blockchain a transaction representing a payment token that includes the buyer identifier,
the receipt value, the translation rate, and a status of unclaimed. In some embodiments, the payment token is
specified as unclaimed so that the payment token cannot be used for payment. In some embodiments, the
payment token is specified as claimed when a claimed criterion is satisfied so that the payment token can be
used for payment.
[0061] In some embodiments, a method performed by one or more computing systems is provided for securely
conduction a transaction to reduce risk of a fraudulent transaction. The method receives from an e-commerce
site an indication of a transaction and information relating to the purchaser. Upon determining that the purchaser
has an account with a digital payment system, the method sends to a personal device of the purchaser an
indication of the transaction. The method receives from the personal device of the purchaser an indication that
the purchaser has approved the transaction. The method settles the transaction using a financial account linked to
the account of the purchaser. The method notifies the e-commerce site that the transaction has been settled. In
some embodiments, upon determining that the purchaser does not have an account with the digital payment
system, the method creates an account for that purchaser that is linked to a financial account identified in the
information relating to the purchaser.
[0062] Although the subject matter has been described in language specific to structural features and/or acts, it is
to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific
features or acts described above. Rather, the specific features and acts described above are disclosed as example
forms of implementing the claims. Accordingly, the invention is not limited except as by the appended claims.
* * * * *