U.S. patent application number 16/127283 was filed with the patent office on 2019-03-14 for tokens or crypto currency using smart contracts and blockchains.
This patent application is currently assigned to Vijay K. Madisetti. The applicant listed for this patent is Arshdeep Bahga, Vijay K. Madisetti. Invention is credited to Arshdeep Bahga, Vijay K. Madisetti.
Application Number | 20190081789 16/127283 |
Document ID | / |
Family ID | 65631730 |
Filed Date | 2019-03-14 |
![](/patent/app/20190081789/US20190081789A1-20190314-D00000.png)
![](/patent/app/20190081789/US20190081789A1-20190314-D00001.png)
![](/patent/app/20190081789/US20190081789A1-20190314-D00002.png)
![](/patent/app/20190081789/US20190081789A1-20190314-D00003.png)
![](/patent/app/20190081789/US20190081789A1-20190314-D00004.png)
![](/patent/app/20190081789/US20190081789A1-20190314-D00005.png)
![](/patent/app/20190081789/US20190081789A1-20190314-D00006.png)
![](/patent/app/20190081789/US20190081789A1-20190314-D00007.png)
![](/patent/app/20190081789/US20190081789A1-20190314-D00008.png)
![](/patent/app/20190081789/US20190081789A1-20190314-D00009.png)
![](/patent/app/20190081789/US20190081789A1-20190314-D00010.png)
View All Diagrams
United States Patent
Application |
20190081789 |
Kind Code |
A1 |
Madisetti; Vijay K. ; et
al. |
March 14, 2019 |
TOKENS OR CRYPTO CURRENCY USING SMART CONTRACTS AND BLOCKCHAINS
Abstract
A method of exchanging value across a blockchain network
comprising receiving first and second transaction smart contracts,
recording the first transaction smart contract to the second
transaction smart contract, and registering global variable names
and defining values thereof. The method further comprises receiving
a transaction notification and recording the transaction to the
second transaction smart contract.
Inventors: |
Madisetti; Vijay K.; (Johns
Creek, GA) ; Bahga; Arshdeep; (Chandigarh,
IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Madisetti; Vijay K.
Bahga; Arshdeep |
Johns Creek
Chandigarh |
GA |
US
IN |
|
|
Assignee: |
Madisetti; Vijay K.
Johns Creek
GA
|
Family ID: |
65631730 |
Appl. No.: |
16/127283 |
Filed: |
September 11, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62557820 |
Sep 13, 2017 |
|
|
|
62618784 |
Jan 18, 2018 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/401 20130101;
G06Q 2220/00 20130101; G06Q 40/02 20130101; H04L 2209/38 20130101;
H04L 9/0637 20130101; H04L 9/3247 20130101; H04L 9/3213 20130101;
H04L 9/3239 20130101; H04L 2209/56 20130101 |
International
Class: |
H04L 9/32 20060101
H04L009/32; H04L 9/06 20060101 H04L009/06; G06Q 20/40 20060101
G06Q020/40; G06Q 40/02 20060101 G06Q040/02 |
Claims
1. A method of exchanging value across a blockchain network
comprising: receiving a first transaction smart contract comprising
a transaction amount global variable name request and a transaction
amount; recording the first transaction to a second transaction
smart contract on a first blockchain network; registering the first
transaction amount global variable name to a global variable name
system, defining a transaction amount global variable; defining a
value of the transaction amount global variable responsive to the
transaction amount; receiving a second transaction smart contract
comprising a second transaction global variable name request and a
second transaction amount; registering the second transaction
global variable name request to the global variable name system,
defining a second transaction global variable; defining a value of
the second transaction global variable responsive to the second
transaction amount; receiving a transaction notification comprising
the second transaction global variable name and a transaction
value; recording the transaction notification to the second smart
contract; and updating the value of the second transaction global
variable responsive to the transaction value.
2. The method of exchanging value of claim 1 wherein updating the
value of the second transaction global variable comprises:
publishing the updated value of the second transaction global
variable to a first managed topic on a first messaging server; and
transmitting the content published to the managed topic to a first
subscriber; wherein the receipt of the content published to the
first managed topic by the first subscriber initiates a smart
contract transaction for a first smart contract, the first smart
contract being recorded on a first blockchain network.
3. The method of exchanging value of claim 1 wherein registering
the transaction amount global variable, registering the second
transaction global variable, and registering the registering the
second transaction global variable each comprise performing a
global variable registration process comprising: receiving a
request for to register a global variable name at a global variable
name registrar from a user, defining a new global variable;
defining an owner for the new global variable at a global variable
name registry; defining a resolver for the new global variable at
the global variable name registry; and defining a value of the new
global variable.
4. The method of claim 3 further comprising performing an updating
procedure to update the value of the new global variable, the
updating procedure comprising: receiving a trigger generated by a
smart contract data source on a first messaging server, the trigger
comprising an updated value of the new global variable; publishing
the updated value comprised by the trigger to a first managed topic
associated with the new global variable on the first messaging
server; and transmitting the updated value comprised by the trigger
that is published to the managed topic to a first subscriber;
wherein receipt of the content published to the first managed topic
by the first subscriber initiates a smart contract transaction for
a first smart contract, the first smart contract being recorded on
the first blockchain network.
5. The method of exchanging value of claim 1 further comprising:
receiving a collateral input; and recording the collateral input to
a collateral smart contract on the first blockchain network.
6. The method of claim 5 wherein the collateral input is a
collateral token generated by: receiving a tangible asset
collateral deposit; generating a collateral token associated with
the tangible asset collateral deposit; and transmitting the
collateral token.
7. The method of claim 6 wherein the tangible asset is received by
a third party and the collateral token is generated by the third
party.
8. The method of exchanging value of claim 5 further comprising:
receiving a repayment notification; recording the repayment
notification to the second transaction smart contract; updating the
value of the second transaction global variable; and recording a
collateral release to the collateral smart contract.
9. The method of claim 5 further comprising: receiving a default
notification; recording the default notification to the second
transaction smart contract; updating the value of the second
transaction global variable; and recording a collateral release to
the collateral smart contract directed to the second transaction
global variable.
10. The method of claim 5 wherein the collateral input comprises at
least one of cryptocurrency or a collateral token.
11. The method of claim 1 further comprising: receiving an
installation payment; recording an installation payment
notification to the second transaction smart contract; updating the
second transaction global variable responsive to a value of the
installation payment; and transferring at least a portion of the
value of the installation payment to an entity associated with the
second transaction global variable.
12. The method of claim 1 wherein the first transaction smart
contract further comprises a loan duration and a loan interest
rate, collectively defining borrower conditions, the method further
comprising: registering a loan duration global variable name to the
global variable name system, defining a loan duration global
variable; defining a value of the loan duration global variable
responsive to the transaction amount; registering a loan interest
rate global variable name to the global variable name system,
defining a loan interest rate global variable; and defining a value
of the loan interest rate global variable responsive to the loan
interest rate.
13. The method of claim 12 further comprising: receiving a
plurality of lending offers from a plurality of lenders, each
lending offer comprising an amount to lend, a loan duration, and
expected returns, collectively defining lending pool conditions;
recording the plurality of lending offers, defining a lending pool,
to a second transaction smart contract on the first blockchain
network, the values of the lending offers of the plurality of
lending offers defining lending pool conditions; determining if the
borrower conditions match the lending pool conditions; matching a
lending offer from the second transaction smart contract to the
first transaction; recording a borrower smart contract between the
borrower and the second transaction smart contract; and recording a
lender smart contract between the lender associated with the
matched lending offer and the second transaction smart
contract.
14. The method of claim 12 further comprising: receiving multiple
pluralities of lending offers from a plurality of lenders, each
lending offer comprising an amount to lend, a loan duration, and
expected returns; recording each plurality of lending offers,
defining a lending pool, to a second transaction smart contract on
the first blockchain network, the values of the lending offers of
the plurality of lending offers defining lending pool conditions;
recording a plurality of second transaction smart contracts to a
pool of pools smart contract on the first blockchain network;
determining if the borrower conditions match the lending pool
conditions of any of the plurality of second transaction smart
contracts comprised by the pool of pools smart contract; matching a
lending offer from the pool of pools smart contract to the first
transaction; recording a borrower smart contract between the
borrower and the pool of pools smart contract; recording a
pool-to-pool smart contract between the pool of pools smart
contract and the second transaction smart contract; and recording a
lender smart contract between the lender associated with the
matched lending offer and the second transaction smart
contract.
15. The method of claim 1 further comprising: receiving borrower
identity information associated with a borrower; receiving a
borrower credit rating; and recording the borrower credit rating to
a credit rating and reputation smart contract on the first
blockchain network.
16. A method of exchanging value across a blockchain network
comprising: receiving a first transaction smart contract comprising
a transaction amount global variable name request and a transaction
amount; recording the first transaction to a second transaction
smart contract on a first blockchain network; registering the first
transaction amount global variable name to a global variable name
system, defining a transaction amount global variable; defining a
value of the transaction amount global variable responsive to the
transaction amount; receiving a second transaction smart contract
comprising a second transaction global variable name request and a
second transaction amount; registering the second transaction
global variable name request to the global variable name system,
defining a second transaction global variable; defining a value of
the second transaction global variable responsive to the second
transaction amount; receiving a transaction notification comprising
the second transaction global variable name and a transaction
value; receiving a transaction notification; recording the
transaction notification to the second transaction smart contract;
updating a value of the second transaction global variable
responsive to the transaction notification comprising the steps of:
publishing the updated value of the second transaction global
variable to a first managed topic on a first messaging server; and
transmitting the content published to the managed topic to a first
subscriber; and transferring at least a portion of the value of the
transaction notification to an entity associated with the second
transaction global variable; wherein the receipt of the content
published to the first managed topic by the first subscriber
initiates a smart contract transaction for a first smart contract,
the first smart contract being recorded on a first blockchain
network.
17. The method of claim 16 wherein the first transaction further
comprises a loan duration and a loan interest rate, the method
further comprising: registering a loan duration global variable
name to the global variable name system, defining a loan duration
global variable; defining a value of the loan duration global
variable responsive to the transaction amount; registering a loan
interest rate global variable name to the global variable name
system, defining a loan interest rate global variable; and defining
a value of the loan interest rate global variable responsive to the
loan interest rate.
18. The method of claim 17 wherein the first transaction further
comprises a loan duration and a loan interest rate, collectively
defining borrower conditions, the method further comprising:
receiving a plurality of lending offers from a plurality of
lenders, each lending offer comprising an amount to lend, a loan
duration, and expected returns, collectively defining lending pool
conditions; recording the plurality of lending offers, defining a
lending pool, to a second transaction smart contract on the first
blockchain network, the values of the lending offers of the
plurality of lending offers defining lending pool conditions;
determining if the borrower conditions match the lending pool
conditions; matching a lending offer from the second transaction
smart contract to the first transaction; recording a borrower smart
contract between the borrower and the second transaction smart
contract; and recording a lender smart contract between the lender
associated with the matched lending offer and the second
transaction smart contract.
19. The method of claim 17 wherein the first transaction further
comprises a loan duration and a loan interest rate, collectively
borrower conditions, the method further comprising: receiving
multiple pluralities of lending offers from a plurality of lenders,
each lending offer comprising an amount to lend, a loan duration,
and expected returns; recording each plurality of lending offers,
defining a lending pool, to a second transaction smart contract on
the first blockchain network, the values of the lending offers of
the plurality of lending offers defining lending pool conditions;
recording a plurality of second transaction smart contracts to a
pool of pools smart contract on the first blockchain network;
determining if the borrower conditions match the lending pool
conditions of any of the plurality of second transaction smart
contracts comprised by the pool of pools smart contract; matching a
lending offer from the pool of pools smart contract to the first
transaction; recording a borrower smart contract between the
borrower and the pool of pools smart contract; recording a
pool-to-pool smart contract between the pool of pools smart
contract and the second transaction smart contract; and recording a
lender smart contract between the lender associated with the
matched lending offer and the second transaction smart
contract.
20. A system for exchanging value across a blockchain network
comprising: a processor; a data store positioned in communication
with the processor; and a network communication device positioned
in communication with each of the processor, the data store, and a
network; wherein the network communication device is operable to
receive a first transaction smart contract comprising a transaction
amount global variable name request and a transaction amount;
wherein the processor is operable to record the first transaction
to a second transaction smart contract on a first blockchain
network; wherein the processor is operable to register the first
transaction amount global variable name to a global variable name
system, defining a transaction amount global variable; wherein the
network communication device is operable to receive a second
transaction smart contract comprising a second transaction global
variable name request and a second transaction amount; wherein the
processor is operable to register the second transaction global
variable name request to the global variable name system, defining
a second transaction global variable; wherein the network
communication device is operable to receive a transaction
notification comprising the second transaction global variable name
and a transaction value; wherein the processor is operable to
record the transaction notification to the second transaction smart
contract; and wherein the processor is operable to update a value
of the second transaction global variable responsive to the
transaction value.
Description
RELATED APPLICATIONS
[0001] This application claims the benefit under 35 U.S.C. .sctn.
119(e) of U.S. Provisional Patent Application Ser. No. 62/557,820
filed on Sep. 13, 2017 and titled Tokens or Crypto Currency for
Change Using Smart Contracts and Blockchains, and U.S. Provisional
Patent Application Ser. No. 62/618,784 filed on Jan. 18, 2018 and
titled Additional Features of CoinBank and nCash NCC Tokens, the
entire contents of which is herein by reference.
FIELD OF THE INVENTION
[0002] The present invention relates to systems and methods for
improving the linking smart contracts in transactions on a
blockchain network.
BACKGROUND
[0003] Blockchain is a distributed and public ledger which
maintains records of all the transactions. A blockchain network is
a truly peer-to-peer network and it does not require a trusted
central authority or intermediaries to authenticate or to settle
the transactions or to control the network infrastructure. Users
can interact and transact with the blockchain networks through
Externally Owned Account (EOAs), which are owned and controlled by
the users. Each EOA has a balance (in certain units of a
Cryptocurrency associated with the Blockchain network) associated
with it. EOAs do not have any associated code. All transactions on
a blockchain network are initiated by EOAs. These accounts can send
transactions to other EOAs or contract accounts. Another type of
accounts support by second generation programmable Blockchain
platforms are the Contract Accounts. A Contract Account is created
and owned by an EOA and is controlled by the associated contract
code which is stored with the account. The contract code execution
is triggered by transactions sent by EOAs or messages sent by other
contracts.
[0004] Blockchain networks can either be public or private. Public
blockchain networks are free and open to all and any user can
create an account and participate in the consensus mechanism on a
public blockchain and view all the transactions on the network.
Private blockchain networks are usually controlled and operated by
a single organization and the transactions can be viewed only by
the users within the organization. Public blockchain networks are
usually unpermissioned or permissionless, as any node can
participate in consensus process. Some public blockchain networks
adopt a permissioned model where the consensus process is
controlled by a pre-selected set of nodes. Private blockchain
networks usually adopt the permissioned model. While public
blockchain networks can be considered as fully decentralized,
private blockchain networks are partially decentralized.
[0005] Organizations can have multiple private blockchain networks
where each network is dedicated to a specific use case or
department or business vertical. The blockchain networks within an
organization may be created either using the same blockchain
platform or technology or with different platforms or
technologies.
[0006] On each blockchain network, a user can create multiple
Externally Owned Accounts (EOAs). Each Externally Owned Account
(EOA) has a public-private keypair associated with it. The account
address is derived from the public key. When a new EOA is created,
a keyfile is created which has the public and private keys
associated with the account. The private key is encrypted with the
password which is provided while creating the account. For sending
transactions to other accounts, the private key and the account
password are required.
[0007] This background information is provided to reveal
information believed by the applicant to be of possible relevance
to the present invention. No admission is necessarily intended, nor
should be construed, that any of the preceding information
constitutes prior art against the present invention.
SUMMARY OF THE INVENTION
[0008] With the above in mind, embodiments of the present invention
are directed to a system and associated methods for exchange of
information, value or tokens within and between blockchain networks
and the real physical world.
[0009] In some embodiments, the systems, apparatus and methods
allow creation and deployment of scalable blockchain applications
that rely on a large number of smart contracts that interact with
each other through the use of either a cloud-based billboard
architecture or a blockchain-based billboard architecture. This
architecture allows extension of existing blockchain applications
to deploy smart contracts that use global shared variables (within
languages, such a Solidity) to exchange information with each
other. The billboard architecture allows the integration of
scalable information exchange between the real-world (e.g.,
triggers such as loan payments or sales of products) and the
systems of smart contracts and oracles, seamlessly and efficiently.
Several familiar programming models such as push/pull,
publish/subscribe and consumer/producer may be easily supported for
production deployment.
[0010] Decentralized blockchain applications and smart contracts in
second and third generation blockchain platforms such as Ethereum,
Hyperledger, Neo, Lisk and EOS that rely on a large number of
linked smart contracts interacting with each other can benefit from
the proposed Bulletin Board Messaging Framework (BBMF) and the
Global Variable Name System (GVNS) technologies. In current
implementations of applications with linked smart contracts, one
smart contract can send a transaction to another contract or
reference public state variables of other contracts. However, such
calls and variable references must be coded in the smart contract
and the contract code once deployed cannot be changed. If one
contract in a system of linked contracts must be changed then it
would need re-deployment of all the other linked contracts as the
code has to be changed. BBMF and GVNS technologies allow the
seamless integration of scalable information exchange between the
real-world and the systems of smart contracts and oracles,
seamlessly and efficiently. Further, legacy blockchain-based code
can be seamlessly upgraded and functionality modified through
change in the BBMF framework through new mapping and distribution
from older public state variables to new or redefined ones.
[0011] In some embodiments, the method and systems may further
comprise fintech and enterprise applications, including but not
limited retail payments, loyalty rewards and peer-to-peer lending
application (referred as nCash mobile application) and an
associated platform (referred as nCash Network) that provide the
following features: [0012] Scalable blockchain architecture that
links to the real-world: Decentralized applications and systems
that are based on a very large number of interacting smart
contracts that are coupled with and responsive to real world
triggers and events, using a novel billboard-based information and
value distribution system. [0013] Secure Blockchain Payments: The
platform is built on second generation programmable Blockchain
network (such as Ethereum) and allows individuals to securely send
and receive payments. [0014] Pay At Merchant Stores: The nCash
application allows users to spend crypto or fiat currencies managed
by the platform at affiliated merchant stores. [0015] Get Change in
Tokens: Users no longer have to deal with the inconvenience of
receiving loose change back when making purchases, rather they can
receive the change into their mobile application wallet. [0016]
Loyalty Rewards & Offers: Users can get exclusive loyalty
rewards, discount offers and cashbacks by paying with nCash app at
affiliated merchant stores. [0017] Supports Multiple Currencies:
The nCash mobile application wallet is capable of managing multiple
layers of currencies (fiat currency, cryptocurrency and ERC-20
tokens). Users can buy the native tokens named nCash Coins (NCC) by
paying with credit or debit card, ACH bank transfer, or any of the
supported cryptocurrencies (including Bitcoin, Ether, Litecoin, and
more). [0018] ERC20 Token: nCash coins (NCC) are based on the
ERC-20 token standard. NCC tokens can be purchased with any of the
supported fiat or crypto currencies in the nCash app. [0019] Chat
& Transact with Contacts: With nCash users can chat and send
payments, or request payments from their contacts. [0020] Borrow
& Lend Coins: nCash application includes a lending marketplace
and supports borrowing and lending of nCash coins. [0021] Multiple
Account Types: nCash application supports customer, merchant admin
and merchant operator account types.
[0022] Additionally, embodiments of the present invention are
directed to a method of exchanging value across a blockchain
network comprising receiving a first transaction smart contract,
that may be a transaction, comprising a transaction amount global
variable name request and a transaction amount, recording the first
transaction to a second transaction smart contract on a first
blockchain network, and registering the first transaction amount
global variable name to a global variable name system, defining a
transaction amount global variable. The method further comprises
defining a value of the transaction amount global variable
responsive to the transaction amount, receiving a second
transaction smart contract, which may also be a financial
transaction, comprising a second transaction global variable name
request and a second transaction amount, and registering the second
transaction global variable name request to the global variable
name system, defining a second transaction global variable. The
method further comprises defining a value of the second transaction
global variable responsive to the second transaction amount,
receiving a transaction notification comprising the second
transaction global variable name and a transaction value, recording
the transaction notification to the second smart contract, and
updating the value of the second transaction global variable
responsive to the transaction value.
[0023] In some embodiments, updating the value of the second
transaction global variable may comprise publishing the updated
value of the second transaction global variable to a first managed
topic on a first messaging server and transmitting the content
published to the managed topic to a first subscriber. The receipt
of the content published to the first managed topic by the first
subscriber may initiate a smart contract transaction for a first
smart contract, the first smart contract being recorded on a first
blockchain network.
[0024] Registering the transaction amount global variable,
registering the second transaction global variable, and registering
the registering the second transaction global variable each
comprise performing a global variable registration process may
comprise receiving a request for to register a global variable name
at a global variable name registrar from a user, defining a new
global variable, defining an owner for the new global variable at a
global variable name registry, defining a resolver for the new
global variable at the global variable name registry, and defining
a value of the new global variable. Additionally, the method may
further comprise performing an updating procedure to update the
value of the new global variable, the updating procedure comprising
receiving a trigger generated by a smart contract data source on a
first messaging server, the trigger comprising an updated value of
the new global variable, publishing the updated value comprised by
the trigger to a first managed topic associated with the new global
variable on the first messaging server, and transmitting the
updated value comprised by the trigger that is published to the
managed topic to a first subscriber. Receipt of the content
published to the first managed topic by the first subscriber may
initiate a smart contract transaction for a first smart contract,
the first smart contract being recorded on the first blockchain
network.
[0025] In some embodiments, the method may further comprise
receiving a collateral input and recording the collateral input to
a collateral smart contract on the first blockchain network. The
collateral input may be a collateral token generated by receiving a
tangible asset collateral deposit, generating a collateral token
associated with the tangible asset collateral deposit, and
transmitting the collateral token. The tangible asset may be
received by a third party and the collateral token may be generated
by the third party. In some embodiments, the method may further
comprise receiving a repayment notification, recording the
repayment notification to the second transaction smart contract,
updating the value of the second transaction global variable, and
recording a collateral release to the collateral smart contract. In
some embodiments, the method may further comprise receiving a
default notification, recording the default notification to the
second transaction smart contract, updating the value of the second
transaction global variable, and recording a collateral release to
the collateral smart contract directed to the second transaction
global variable. The collateral input may comprise at least one of
cryptocurrency or a collateral token.
[0026] In some embodiments, the method may further comprise
receiving an installation payment, recording an installation
payment notification to the second transaction smart contract,
updating the second transaction global variable responsive to a
value of the installation payment, and transferring at least a
portion of the value of the installation payment to an entity
associated with the second transaction global variable.
[0027] In some embodiments, the first transaction smart contract
may further comprise a loan duration and a loan interest rate,
collectively defining borrower conditions, the method further
comprising registering a loan duration global variable name to the
global variable name system, defining a loan duration global
variable, defining a value of the loan duration global variable
responsive to the transaction amount, registering a loan interest
rate global variable name to the global variable name system,
defining a loan interest rate global variable, and defining a value
of the loan interest rate global variable responsive to the loan
interest rate. The method may further comprise receiving a
plurality of lending offers from a plurality of lenders, each
lending offer comprising an amount to lend, a loan duration, and
expected returns, collectively defining lending pool conditions,
recording the plurality of lending offers, defining a lending pool,
to a second transaction smart contract on the first blockchain
network, the values of the lending offers of the plurality of
lending offers defining lending pool conditions, determining if the
borrower conditions match the lending pool conditions, matching a
lending offer from the second transaction smart contract to the
first transaction, recording a borrower smart contract between the
borrower and the second transaction smart contract, and recording a
lender smart contract between the lender associated with the
matched lending offer and the second transaction smart contract.
Additionally, the method may further comprise receiving multiple
pluralities of lending offers from a plurality of lenders, each
lending offer comprising an amount to lend, a loan duration, and
expected returns, recording each plurality of lending offers,
defining a lending pool, to a second transaction smart contract on
the first blockchain network, the values of the lending offers of
the plurality of lending offers defining lending pool conditions,
recording a plurality of second transaction smart contracts to a
pool of pools smart contract on the first blockchain network,
determining if the borrower conditions match the lending pool
conditions of any of the plurality of second transaction smart
contracts comprised by the pool of pools smart contract, matching a
lending offer from the pool of pools smart contract to the first
transaction, recording a borrower smart contract between the
borrower and the pool of pools smart contract, recording a
pool-to-pool smart contract between the pool of pools smart
contract and the second transaction smart contract, and recording a
lender smart contract between the lender associated with the
matched lending offer and the second transaction smart
contract.
[0028] In some embodiments, the method may further comprise
receiving borrower identity information associated with a borrower,
receiving a borrower credit rating, and recording the borrower
credit rating to a credit rating and reputation smart contract on
the first blockchain network.
[0029] Additional embodiments of the inventions may be directed to
a system for exchanging value across a blockchain network
comprising a processor, a data store positioned in communication
with the processor, and a network communication device positioned
in communication with each of the processor, the data store, and a
network. The network communication device may be operable to
receive a first transaction smart contract comprising a transaction
amount global variable name request and a transaction amount. The
processor may be operable to record the first transaction to a
second transaction smart contract on a first blockchain network and
register the first transaction amount global variable name to a
global variable name system, defining a transaction amount global
variable. Additionally, the network communication device may be
operable to receive a second transaction smart contract comprising
a second transaction global variable name request and a second
transaction amount. Furthermore, the processor may be operable to
register the second transaction global variable name request to the
global variable name system, defining a second transaction global
variable. The network communication device may be operable to
receive a transaction notification comprising the second
transaction global variable name and a transaction value. The
processor may be operable to record the transaction notification to
the second transaction smart contract and update a value of the
second transaction global variable responsive to the transaction
value.
BRIEF DESCRIPTION OF THE DRAWINGS
[0030] FIG. 1 is a schematic diagram of a retail payments, loyalty
rewards and peer-to-peer lending system that uses smart contracts
and blockchain.
[0031] FIG. 2 is an illustration of a process for retail payments
where a customer pays in cash at a merchant kiosk/application/point
of sale application or hardware device that is aware of the nCash
platform, and instead of receiving loose change back receives
digital tokens in the nCash mobile application wallet, according to
an embodiment of the invention.
[0032] FIG. 3 is an illustration of a process for retail payments
where a customer pays in cash and instead of receiving loose change
back receives digital tokens from a merchant account in the nCash
mobile application, according to an embodiment of the
invention.
[0033] FIG. 4 is an illustration of the components of the nCash
mobile application wallet, according to an embodiment of the
invention.
[0034] FIG. 5 is an illustration a process for QR-code based
payment request and authorization, according to an embodiment of
the invention.
[0035] FIG. 6 is an illustration of a process for buying coins with
credit or debit card, according to an embodiment of the
invention.
[0036] FIG. 7 is an illustration of a process for buying coins with
ACH Bank Transfer, according to an embodiment of the invention.
[0037] FIG. 8 is an illustration of a process for buying coins with
Cryptocurrencies, according to an embodiment of the invention.
[0038] FIG. 9 is an illustration a process for withdrawing coins to
a linked bank account, according to an embodiment of the
invention.
[0039] FIG. 10 is an illustration of the smart contracts involved
in the nCash retail payments, loyalty rewards and peer-to-peer
lending platform, according to an embodiment of the invention.
[0040] FIG. 11 is an illustration of a process for peer-to-peer
lending, according to an embodiment of the invention.
[0041] FIG. 12 is a schematic diagram of the blockchain-based
peer-to-peer lending system, according to an embodiment of the
invention.
[0042] FIG. 13 is an illustration the multi-signature collateral
contract used by the peer-to-peer lending system, according to an
embodiment of the invention.
[0043] FIG. 14 is an illustration of a process for chaining of
loans, according to an embodiment of the invention.
[0044] FIG. 15 is an illustration of a process for lending with
cryptocurrency or tokens as collateral where the borrower
successfully repays the loan, according to an embodiment of the
invention.
[0045] FIG. 16 is an illustration of a process for lending with
cryptocurrency or tokens as collateral where the borrower fails to
repay the loan, according to an embodiment of the invention.
[0046] FIG. 17 is an illustration of a process for lending with
physical assets as collateral, according to an embodiment of the
invention.
[0047] FIG. 18 is an illustration of the transaction fee involved
for buying and selling of coins, according to an embodiment of the
invention.
[0048] FIG. 19 is an illustration of the smart contracts related to
the lending platform and the interactions of borrowers and lenders
with the smart contracts, according to an embodiment of the
invention.
[0049] FIG. 20 is an illustration of a process for issuing cashback
and discounts using smart contracts, according to an embodiment of
the invention.
[0050] FIG. 21 is an illustration of a peer-to-pool-to-peer (P2P2P)
lending model, according to an embodiment of the invention.
[0051] FIG. 22 is an illustration of a lending pool generator for
generating lending pool smart contracts, according to an embodiment
of the invention.
[0052] FIG. 23 is an illustration of a matching engine for matching
borrowers to lending pools, according to an embodiment of the
invention.
[0053] FIG. 24 is an illustration of feeding external data to
lending pool contracts using an oracle, according to an embodiment
of the invention.
[0054] FIG. 25 is an illustration of channels and triggers for
lending pools, according to an embodiment of the invention.
[0055] FIG. 26 is an illustration of smart contracts involved in a
lending pool, according to an embodiment of the invention.
[0056] FIG. 27 is an illustration of a pool-of-pools comprised of
multiple lending pools, according to an embodiment of the
invention.
[0057] FIG. 28 is an illustration of a lending pool smart contract
structure and transactions, according to an embodiment of the
invention.
[0058] FIG. 29 is an exemplary classification of lending pools
based on their risk and returns, according to an embodiment of the
invention.
[0059] FIG. 30 is an illustration of an alliance of merchants with
interoperable loyalty points, according to an embodiment of the
invention.
[0060] FIG. 31 is an illustration of a distributed messaging
framework called Bulleting Board Messaging Framework (BBMF)
according to an embodiment of the invention.
[0061] FIG. 32 is an illustration of consumer/subscriber actions
supported in the publish-subscribe messaging framework illustrated
in FIG. 31.
[0062] FIG. 33 is an illustration of a smart contract data source
that uses an external publisher client to publish messages to the
publish-subscribe messaging framework, according to an embodiment
of the invention.
[0063] FIG. 34 is an illustration of a smart contract data source
that uses an integrated publisher client to publish messages to the
publish-subscribe messaging framework, according to an embodiment
of the invention.
[0064] FIG. 35 is an illustration of the message format for the
publish-subscribe messaging framework, according to an embodiment
of the invention.
[0065] FIG. 36 is an illustration of a global variable name system
being updated by a consumer of the publish-subscribe messaging
framework, according to an embodiment of the invention.
[0066] FIG. 37 is an illustration of the architecture of a global
variable name system, according to an embodiment of the
invention.
[0067] FIG. 38 is an illustration of a blockchain checkpointing
approach in the publish-subscribe messaging framework, according to
an embodiment of the invention.
[0068] FIG. 39 is an illustration of global variable sharing across
smart contracts, according to an embodiment of the invention.
[0069] FIG. 40 is an exemplary implementation of a Bulletin Board
Publisher/Producer client and Consumer/Subscriber client, according
to an embodiment of the invention.
[0070] FIG. 41 is an exemplary interface of the nCash mobile
application, according to an embodiment of the invention.
[0071] FIG. 42 is an exemplary interface of the nCash mobile
application showing peer-to-peer lending options, according to an
embodiment of the invention.
[0072] FIG. 43 is an exemplary interface of the nCash mobile
application showing different types of transactions, according to
an embodiment of the invention.
[0073] FIG. 44 is an exemplary interface of the nCash mobile
application showing chats and payments interface, according to an
embodiment of the invention.
[0074] FIG. 45 is an illustration of the nCash mobile application
features for different types of accounts, according to an
embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0075] The present invention will now be described more fully
hereinafter with reference to the accompanying drawings, in which
preferred embodiments of the invention are shown. This invention
may, however, be embodied in many different forms and should not be
construed as limited to the embodiments set forth herein. Rather,
these embodiments are provided so that this disclosure will be
thorough and complete, and will fully convey the scope of the
invention to those skilled in the art. Those of ordinary skill in
the art realize that the following descriptions of the embodiments
of the present invention are illustrative and are not intended to
be limiting in any way. Other embodiments of the present invention
will readily suggest themselves to such skilled persons having the
benefit of this disclosure. Like numbers refer to like elements
throughout.
[0076] Although the following detailed description contains many
specifics for the purposes of illustration, anyone of ordinary
skill in the art will appreciate that many variations and
alterations to the following details are within the scope of the
invention. Accordingly, the following embodiments of the invention
are set forth without any loss of generality to, and without
imposing limitations upon, the claimed invention.
[0077] In this detailed description of the present invention, a
person skilled in the art should note that directional terms, such
as "above," "below," "upper," "lower," and other like terms are
used for the convenience of the reader in reference to the
drawings. Also, a person skilled in the art should notice this
description may contain other terminology to convey position,
orientation, and direction without departing from the principles of
the present invention.
[0078] Furthermore, in this detailed description, a person skilled
in the art should note that quantitative qualifying terms such as
"generally," "substantially," "mostly," and other terms are used,
in general, to mean that the referred to object, characteristic, or
quality constitutes a majority of the subject of the reference. The
meaning of any of these terms is dependent upon the context within
which it is used, and the meaning may be expressly modified.
[0079] Referring now to FIG. 1 a schematic diagram of a retail
payments, loyalty rewards and peer-to-peer lending system that uses
smart contracts and blockchain, is described in more detail. A user
100 and a merchant 102 may complete a transaction through use of an
application and presentation layer 104. The application and
presentation layer 104 may comprise a web interface 106 and/or a
mobile application 108. Elements of the application and
presentation layer 104 may be the client-facing element of a
platform/application services layer 110. The platform/application
services layer 110 may comprise security features 112, such as a
user identity and access management system 114. The
platform/application services layer 110 may further comprise
integration services 116, such as, for example, a messaging service
118 or a connector service for applications, cloud services, and
token exchanges 120. The platform/application services layer 110
may further comprise configuration management features 122. The
configuration management features 122 may include an nCash portal
124, an incentives management system 126, and a license manager
128. The platform/application services layer 110 may further
comprise accounting and transaction services 130, such as a change
management framework 132, a token framework 469, an incentives
disbursement framework 136, a lending framework 138, and an nCash
wallet 140. The platform/application services layer 110 may further
comprise data management and analytics services 142, such as
analytics and reporting systems 144, an incentives bidding system
146, a loan matching system 148, a recommendation system 150, and
an advertisement and promotions system 152. The
platform/application services layer 110 may function on an
infrastructure layer 154 that may comprise one or more of
blockchain networks 156, decentralized storage platforms 158,
decentralized messaging platforms 160, or cloud infrastructure 162,
such as cloud computational resources, cloud storage resources, or
cloud networking resources.
[0080] Referring now to FIG. 2 a process flow for retail payments
where a customer pays in cash and instead of receiving loose change
back, receives the change as digital tokens (nCash coins--"NCC") in
the nCash mobile application, is described in more detail. Customer
200 pays for the items purchased or rented at a store in cash at
step 204. Customer 200 opens the nCash app and displays a barcode
of the customer's nCash account number at step 206. The merchant
kiosk/application/point of sale application or hardware device that
is aware of the nCash platform 202 scans the barcode and an entry
is added in the ledger to transfer the change to the nCash account
at step 208. At some periodic interval, for example, at the end of
the day, all the transactions to credit the change to nCash
accounts are processed by the payment system. Customer 200 receives
the change back in the nCash App at step 210.
[0081] Referring now to FIG. 3 a process flow for retail payments
where a customer pays in cash and instead of receiving loose change
back receives digital tokens from a merchant account in the nCash
mobile application, is described in more detail. Customer 220 pays
for the items purchased or rented at a store in cash at step 224.
Customer 220 opens the nCash app and displays a QR code at step
226. The merchant/PoS agent 222 that has a mobile/tablet device
with nCash mobile application installed scans the QR code and
enters the change amount and transfers the amount instantly from
the merchant administrator or operator account at step 228. Every
PoS agent 222 has a Merchant nCash app to which some fixed amount
is loaded by the store daily to pay as change. Customer 220
receives the change back in the nCash App at step 230.
[0082] Referring now to FIG. 4 components of an nCash mobile
application wallet 250 are described in more detail. The nCash
wallet 250 may comprise a Fiat currency wallet 252, a
cryptocurrency wallet 258, a coupons and voucher management system
254, and ERC-20 token wallet 260, Escrow accounts 256, and prepaid
credit accounts 262. For making retail payments, a portion or
prepaid deposit in fiat or cryptocurrency wallets 252, 258 can be
considered. The wallet balance of one or both of the fiat and
cryptocurrency wallets 252, 258 may be applied to Escrow 256 as
well where the payment sent by a customer to a merchant is held in
an Escrow account and released when an order is fulfilled.
[0083] Referring now to FIG. 5 a process flow for QR-code based
payment request and authorization, is described in more detail.
Customer 302 uses nCash mobile application to display a QR code
containing customer's nCash wallet address and a one-time receive
code at step 318. The QR code is scanned by a PoS machine 306 or
nCash app with merchant account 308, and a request is sent
including the customer address, the receive code, and the amount to
the nCash network 300 at step 316. The nCash network 300 validates
the receive code and sends a request to customer to authorize the
payment at step 312. Customer 302 authorizes the payment from the
nCash app at step 314. A payment confirmation is sent to the PoS
machine 306 or nCash app with merchant account 308, at step
310.
[0084] Referring now to FIG. 6 a process flow for buying coins with
credit or debit card is described in more detail. Customer 350
sends a request to load an amount to nCash wallet using credit or
debit card at step 356. The nCash network 352 requests for credit
or debit card details of customer 350 at step 358. Customer 350
enters credit or debit card information in the nCash mobile
application at step 360. The card information is then sent to the
fiat payment processor 354 directly without going through the nCash
network 352 at step 360. The fiat payment processor 354 validates
the card information and generates a token which is then sent to
customer's nCash mobile application at step 362. Customer 350
confirms the payment and sends a request containing the card token
and payment amount at step 364. The nCash network 352 sends a
request containing the token and the payment amount to charge the
card to the fiat payment processor 354 at step 366. The fiat
payment processor 354 charges the customer's card for the amount
requested and a payment confirmation is sent to the nCash network
352 at step 368. The nCash network 352 mints new coins (digital
tokens defined in the nCash Token smart contract) and the token
smart contract 370. The nCash network 352 adds these new coins
(digital tokens) the customer's nCash wallet account at step
372.
[0085] Referring now to FIG. 7 a process flow for buying coins with
ACH Bank Transfer is described in more detail. Customer 400 sends a
request to an nCash network 402 to load an amount to nCash wallet
using ACH bank transfer at step 406. The nCash network 402 requests
a temporary account details from a fiat payment processor 404 at
step 408. The fiat payment processor 404 generates a temporary
account and sends details about the temporary account to the nCash
network 402 at step 410. The nCash network 402 then sends the
temporary account details to the customer's nCash mobile
application. Customer 400 sends a payment to the temporary account
using ACH bank transfer at step 414. On receiving the payment, the
fiat payment processor 404 sends a payment confirmation to nCash
network 402 at step 416. The nCash network 402 mints new coins
(digital tokens defined in the nCash Token smart contract) and the
token smart contract 418. The nCash network 402 adds these new
coins (digital tokens) the customer's nCash wallet account at step
420.
[0086] Referring now to FIG. 8 a process flow for buying coins with
Cryptocurrencies is described in more detail. Customer 450 sends a
request to an nCash network 452 to load an amount to nCash wallet
using cryptocurrency at step 456. The nCash network 452 requests a
temporary account details from a crypto payment processor 454 at
step 458. The crypto payment processor 454 generates temporary
account and sends them to the nCash network 452 at step 460. The
nCash network 452 then sends the temporary account details to the
customer's nCash mobile application at step 462. Customer 450 sends
a payment to the temporary account using a cryptocurrency wallet at
step 470. On receiving the payment, the crypto payment processor
454 sends a payment confirmation to nCash network 452 at step 472.
The nCash network 452 mints new coins (digital tokens defined in
the nCash Token smart contract) and the token smart contract 480.
The nCash network 452 adds these new coins (digital tokens) the
customer's nCash wallet account at step 482.
[0087] Referring now to FIG. 9 a process flow for withdrawing coins
to a linked bank account is described in more detail. Customer 500
sends a request to a nCash network 502 to withdraw a certain amount
of tokens to customer's linked bank account in a bank 506 at step
508. On receiving the withdrawal request the nCash network 502
burns coins equivalent to the withdrawal amount from the customer's
account and updates the token smart contract 510. The nCash network
502 then sends a transfer request to the fiat payment processor 504
at step 512. The withdrawal amount is credited by the fiat payment
processor 504 to the customer's linked bank account at the bank 506
at step 514. The fiat payment processor 504 then sends a transfer
confirmation to nCash network 502 at step 518. A withdrawal
confirmation is then sent to customer 500 at step 520.
[0088] Referring now to FIG. 10 examples of smart contracts
involved in the nCash retail payments, loyalty rewards, and
peer-to-peer lending platform are described in more detail. The
nCash blockchain network 588 is a distributed ledger which
maintains records of all the transactions on the nCash network.
Users 554 interact and transact with the blockchain network 588
through Externally Owned Account (EOAs) 550, which are owned and
controlled by the users. Each EOA 550 has an account address 556,
account public-private keys 558 and a balance 560 (in certain units
of a Cryptocurrency associated with the Blockchain network)
associated with it. EOAs do not have any associated code. EOAs may
interact 564 with bank accounts 552 also owned 566 by the user 554
via third party exchanges operable to exchange cryptocurrencies for
fiat currency, which may be deposited in or withdrawn from the bank
account 552.
[0089] All transactions on a blockchain network are initiated by
EOAs. These accounts can send transactions to other EOAs or
contract accounts. Another type of accounts support by second
generation programmable Blockchain platforms are the Contract
Accounts. Smart contracts 570 contain the contract code which
control the associated contract accounts. The smart contracts 570
are deployed on the blockchain network 588. The smart contracts 570
involved in the nCash network are as follows: [0090] Token Contract
572: Token Contract provides the nCash token definition including
token name, symbol, decimal places, token supply, method for token
transfer, and method for checking token balance of an account.
[0091] Token Distribution Contract 580: Token Distribution Contract
defines the token distribution and pricing model and contains
methods for purchasing and claiming tokens, and methods for
withdrawing token sale proceeds. [0092] Incentives Contract 574:
Incentives Contract defines the incentives and triggers and methods
for distributing incentives. [0093] Bidding Contract 582: Bidding
Contract defines the bidding mechanism for allowing merchants to
compete, bid, or pay for the right to add incentives. [0094] Loan
Smart Contract 576: Loan Smart Contract is used to enforce loan
terms, manage release, repayment or extension of loans. [0095]
Identity Smart Contract 584: Identity Smart Contract is used to
link blockchain accounts to real users (borrowers or lenders).
[0096] Credit Rating & Reputation Smart Contract 578: Credit
Rating & Reputation Smart Contract is Used to track credit
scores and reputation of borrowers. [0097] Collateral Smart
Contract 586: Collateral Smart Contract is used to manage locking
up and release of collateral, such as cryptocurrency tokens or
physical assets which may be represented in a tokenized form.
[0098] Referring now to FIG. 11 a process flow for peer-to-peer
lending is described in more detail. A borrowing peer (borrower)
600 creates a first transaction smart contract in the form of a
loan request at step 606. The lending platform 602 advertises the
loan requests to the lending peers (lenders) 604 at step 616. The
lending platform 602 may acquire a credit rating 612 associated
with the borrowing peer 600 and include the credit rating with the
request. The lending peers 604 bid for loans by sending second
transaction smart contracts in the form of loan offers to the
lending platform 602 at step 620. The borrowing peer 600 selects
the best offer and the loan amount is sent to the borrowing peer at
step 610. The borrowing peer 600 repays the loan amount plus the
interest and lending platform fees to the lending platform 602 at
step 608. The lending platform 602 returns the loan amount plus the
profit to the lending peer 604 at step 618. The lending platform
602 may issue loyalty points 614 to borrowing peers 600 and lending
peers 604 upon successful repayment of loans, to incentivize the
borrowing and lending peers 600, 604 to use the lending platform
again for borrowing and lending.
[0099] Referring now to FIG. 12 a schematic diagram of the
blockchain-based peer-to-peer lending system is described in more
detail. The blockchain-based peer-to-peer lending system allows
borrowing peers or borrowers 652 to send loan requests to a
platform 650 which are advertised to lending peers or lenders 656.
Lenders 656 can bid to send a loan at a particular rate and terms
that is enforced by a loan smart contract 668 deployed on a
blockchain network 678. The lending platform 650 can co-exist with
an electronic payments platform. A Borrowers 652 post loan requests
to the platform and rates they can pay and lenders bid for loans
with terms and rates. Platform 650 allows borrowers 652 to
automatically repay loans from their nCash mobile application
wallets (Borrower Crypto wallet) 662 or extend loan for another
term if agreed to. Platform 650 can disburse loans in fiat or
crypto currencies. When a loan is disbursed, the loan amount is
transferred from the Lender Crypto wallet 672 (nCash mobile
application wallet of the lender) to the Borrower Crypto wallet 662
(nCash mobile application wallet of the borrower). The interest
rate is driven by the market. Higher risk means larger rate.
Platform 650 may charge a percentage of the interest rate on every
transaction. Borrower Identity Smart Contracts 658 comprised by the
platform 650 maintain the identity information of the borrowers
652. Lender Identity Smart Contracts 670 comprised by the platform
650 maintain the identity information of the lenders 656. Borrower
Reputation and Credit Rating Smart Contracts 660 comprised by the
platform 650 maintain the reputation information of the borrowers
652 and their credit ratings. Collateral Smart Contracts 664
comprised by the platform 650 maintain collateral information for
the loans. A reputation system and collaterals for loans makes the
lending process more reliable. The lending platform 650 uses smart
contracts to create a credit rating and reputation system for
borrowers. Each repayment and successful loan adds points to the
borrower's credit rating and if a loan is not repaid then points
are deducted from the borrower's credit rating. Such payments may
be transferred to a cryptocurrency wallet 672 for the lender 656.
If a borrower 652 requesting a loan does not repay as per
conditions their credit rating/reputation drops and lenders 656
will charge extremely high rates and higher guarantees for any
subsequent loan requests. The amount of loans could be against a
collateral account by the borrower 652 or having pledges from
guarantor 654 or other peers that they will guarantee a certain
portion of loan. The risk score gets lower of a borrower has
pledges to support him. If risk score suddenly changes existing
lenders get an alert that they can opt for a higher rate or a
shorter repayment term. This forces the borrower to borrow wisely
to protect against these margin calls. Loans issued through the
platform 650 may be secured (backed by collateral) or unsecured. A
Matching Engine 666 of the platform 650 matches loan requests to
loan offers and connects the borrowers to lenders. The platform
matches borrowers to lenders by risk reputation, loan value and
interest terms. For secured loans, borrowers 652 or their
guarantors 654 may present collateral in the form of Cryptocurrency
Tokens or Tokenized Assets. When Cryptocurrency Tokens are
presented as collateral such tokens are transferred by the borrower
to a collateral contract where the tokens are held until the loan
is not repaid. When the loan is repaid, the tokens are released to
the borrower 652. If the loan in not repaid, the tokens are
released to the lender 656. Physical assets (such as gold,
diamonds, real-estate property) may be tokenized and presented as a
collateral. For such cases, a third party may be engaged to verify
the physical assets or keep the assets in their possession till the
loan is repaid. The lending platform 602 may issue loyalty points
614 to borrowing peers 600 and lending peers 604 upon successful
repayment of loans, to incentivize the borrowing and lending peers
600, 604 to use the lending platform again for borrowing and
lending.
[0100] Referring now to FIG. 13 the multi-signature collateral
contract used by the peer-to-peer lending system shown in FIG. 12
is described in more detail. Collateral tokens are stored in a
multi-signature wallet contract 700. Borrower 702, Lender 706,
Lending Platform 704 and optional third-parties 708 hold keys to
the multisig wallet contract 700. The contract requires M-of-N
signatures, typically a majority, (e.g. 2-of-3 or 3-of-5) to
release collateral.
[0101] Referring now to FIG. 14 a process flow for the chaining of
loans is described in more detail. The lending platform supports
chaining loans where a borrowing/lending peer who has a good credit
rating can borrow at low interest rates and lend to one or more
peers who have low credit rating at higher interest rates. For
example, Peer C 752 has good credit rating and sends a loan request
760 and borrows 762 from Peer D 754 at low interest rates. Peer C
752 receives loan requests 758, 766 from Peers A and B 750, 756 who
have low credit rating or risk profile, and then send loans 764,
768 to Peers A and B 750, 756, respectively, at higher interest
rates. A loan can be partitioned into subloans with different
terms. Lenders can fund a portion or fraction of a loan request.
Thus a loan could be satisfied with a dozen microloans each at
different rates. For example, once a big lender jumps in for 30% of
loan, small lenders can jump in to lend at a lower interest rate. A
borrower with low risk can float a loan but open only 25% for bid
to a high value lenders (such as institutions or banks). The
borrower may then open up the loan to the smaller lenders who know
the high value lenders will have vetted this borrower. Lending
peers can buy a bundle of loans at a particular risk for a price or
resell loans. The lending platform allows creating a market for
users to buy, pool and resell loans. The lending platform may allow
a loan to be written off if certain conditions may be met. For
example, if a philanthropist funds a clinic and they treat five
hundred patients in a month, then their loans can get a reduced
rate, or if a farmer creates two jobs his loan may be forgiven.
[0102] Referring now to FIG. 15 a process for lending with
cryptocurrency or tokens as collateral where the borrower
successfully repays the loan is described in more detail. A
Borrower 800 creates a loan request with amount requested and loan
terms at step 808. The lending platform 802 creates a loan contract
810 and advertises the loan request to lenders at step 812. A
Lender 804 agrees to fund the loan at step 814. Next, the Borrower
800 deposits cryptocurrency or tokens as collateral in a collateral
contract 818 at step 816. The Lender 804 funds the loan at step
820. The loan amount is released to the Borrower 800 at step 822.
The Borrower 800 pays loan installments to the Lending Platform 802
at steps 824 and 828 which are released to the Lender 804 at steps
826 and 830. When the loan repayment is complete, the Collateral is
released to the Borrower 800 at step 832, such release being
recorded to the collateral contract 818.
[0103] Referring now to FIG. 16 a process for lending with
cryptocurrency or tokens as collateral where the borrower fails to
repay the loan, is described in more detail. A Borrower 850 creates
a loan request on a lending platform 852 with an amount requested
and loan terms at step 858. The lending platform 852 creates a loan
contract 860 and advertises the loan request to lenders at step
862. A Lender 854 of N lenders 856 to whom the loan request is
advertised agrees to fund the loan at step 864. Next, the Borrower
850 deposits cryptocurrency or tokens as collateral in a collateral
contract 868 at step 866. The Lender 854 funds the loan at step
870. The loan amount is released to the borrower at step 872. When
the Borrower 850 fails to repay the loan as indicated at step 876,
the Collateral is released to the Lender at step 874.
[0104] Referring now to FIG. 17 a process flow for lending with
physical assets as collateral, is described in more detail. A
Borrower 902 creates a loan request on a lending platform 904 with
an amount requested and loan terms at step 858. The lending
platform 904 creates a loan contract 910 and advertises the loan
request to lenders at step 912. A Lender 906 agrees to fund the
loan at step 914. Next, the Borrower 902 transfers physical assets
(such as gold, diamonds or title to real-estate property) to a
Third Party 900 at step 916. The Third Party 900 tokenizes the
assets and transfers the tokens to the borrower at step 918. The
Borrower 902 deposits these tokens as collateral to the lending
platform 904 in a Collateral Contract 922 at step 920. The Lender
906 funds the loan at step 924. The loan amount is released to
Borrower at step 926. The Borrower repays the loan installment to
the lending platform 904 at step 931 and the funds are released to
the lender 906 at step 930. When the loan repayment is complete the
lending platform 904 releases the Collateral (tokens) is released
to the Borrower 902 at step 932. Next, the Borrower 902 transfers
tokens to the third-party 900 at step 934. The third-party 900 then
returns the physical assets to the Borrower 902 at step 936.
[0105] Referring now to FIG. 18 transaction fees involved for
buying and selling of nCash coins is described in more detail.
nCash coins can be purchased by paying in a fiat currency (such as
USD) using credit/debit card 950 or ACH bank transfer 952, or by
paying in a cryptocurrency 954 (such as Bitcoin, Ether). There are
different transaction fees for buying coins with credit/debit card
960, ACH bank transfer, whether automated through an app 962 or
manually 964, or cryptocurrency 970. For transactions between the
nCash network 956 (such as sending coins to another user or
merchant) does not involve any transaction fee. For selling coins
and withdrawing coins to a linked bank account 958, a transaction
fee. for automated transactions through an app 866 or manual
transactions 968. is involved.
[0106] Referring now to FIG. 19 an illustration of smart contracts
related to the lending platform and the interactions of borrowers
and lenders with the smart contracts is described in more detail.
An Identity Smart Contract 1012 is used to link blockchain accounts
to real users, such as an account of a borrower 1000 or a lender
1002. The identity information provided by the borrower 1000 at
step 1004 is recorded in the identity smart contract 1012 in
original or hashed form. Similarly the identity information
provided by the lender 1002 at step 1020 is recorded in the
identity smart contract 1012 in original or hashed form. A Credit
Rating & Reputation Smart Contract 1014 is used to track credit
scores and reputation of a borrower 1000. The credit score of the
borrower 1000 is recorded at step 1006 and updated on each new loan
request, loan repayment or loan default. A Collateral Smart
Contract 1016 is used to manage locking up and release of
collateral, such as cryptocurrency tokens or physical assets which
may be represented in a tokenized form. The borrower 1000 deposits
the collateral tokens to the collateral smart contract 1016 at step
1008. A Loan Smart Contract 1018 is used to enforce loan terms and
manage release, repayment or extension of loans. The information
related to the borrower's 1000 loan requests, loan disbursement
received or loan repayment completion is recorded in the loan smart
contract 1018. Similarly, the information related to the lender's
1002 loan offers, loan disbursement completion, or loan repayment
received is recorded in the loan smart contract 1018. The smart
contracts 1012, 1014, 1016 and 1018 are deployed on the blockchain
network 1026.
[0107] Referring now to FIG. 20 an illustration of a process for
issuing cashback and discounts using smart contracts, is described
in more detail. A customer 1050 makes a transaction to a merchant
with coupon code meeting cashback or discount conditions at step
1052. An incentives smart contract 1054 checks cashback or discount
rules comprised thereby and triggers a cashback or discount if the
transaction meets the cashback or discount criteria at step 1056.
When a cashback or discount is triggered, the token contract 1058
is updated and tokens are transferred from the merchant's account
to the customer's account. The customer 1050 receives a cashback or
discount notification at step 1060. The smart contracts 1054 and
1058 are deployed on the blockchain network 1064 at step 1062.
[0108] Referring now to FIG. 21 an illustration of the
peer-to-pool-to-peer (P2P2P) lending model, is described in more
detail. The lenders 1100, 1102, 1104 contribute to a lenders pool
1108 with conditions. A lender's condition to lend money may
include the amount to lend, the duration of the loans, and expected
returns. The loans are distributed from the lenders pool 1108 with
conditions. Borrowers 1118, 1120, 1122 may submit borrower's
requests 1114 from the lenders pool 1108 through a lending platform
1110. Each borrower request may comprise the borrower's conditions
for a loan. A borrower's condition for borrowing money may include
the amount to borrow, the duration of the loan, and an acceptable
interest rate.
[0109] A matching engine 1112 in the lending platform 1110 uses
smart contracts 1116 to ensure the high level (pool level) and low
level (borrower and lender) constraints are satisfied. A borrower's
requests to borrow money are matched automatically to the lenders
1100, 1102, 1104 and lending pool's 1108 conditions using smart
contracts 1116. Each lender pool (such as pool 1108) is represented
by a smart contract (such as smart contract 1124) in the lending
platform 1110 which controls the pool level behavior and handles
conditions such as different time periods and expected returns for
the lenders 1100, 1102, 1104 and substitution of lenders who exit
the pool 1108 with new lenders, as some of the lenders to the pool
1108 may have different time periods and they will exit and be
substituted by new lenders. Loans are distributed from lender pools
1108 with conditions.
[0110] The peer-to-pool-to-peer (P2P2P) lending model is more
efficient than the existing peer-to-peer (P2P) lending models,
especially when there are large number of lenders/investors who
want to lend loans. Each lender/investor contributes a different
amount of money and specifies the minimum interest they would like
to receive and the period of their loan amounts. Similarly, the
borrowers specify similar terms such as the amount of money to
borrow, duration and acceptable rate of interest. In the P2P2P
lending model the lender's money is pooled into one lending pool
and then lent out to multiple borrowers, while smart contracts
assure payouts to lenders and payments to borrowers, while some
lenders exist and some borrowers' payback. This allows the "pool"
of money that is used for lending, while at the lower level smart
contracts ensure all lower agreements are kept. Lenders' and
borrowers' contributions and withdrawals continually occur, while
the pool remains active as new borrowers and lenders join and
others may leave. A lender may end up lending to N loans and a
borrower may end up borrowing from M lenders over a period where
only P lenders are active at any time (where M>N and M>P).
The smart contracts are thus critical to maintain the integrity of
the records. In the P2P2P lending model, the transactions for pools
merge lower level transactions between peers inside the
blockchain.
[0111] Furthermore, it is contemplated and included within the
scope of the invention that a variety of loans may be executed
utilizing this systems and other systems disclosed herein. The
types of loans requested by borrowers, and offered by lenders, may
include larger value loans, such as those typically offered by
banks, but may also include smaller value loans, including those
for individual consumer transactions (e.g. a routine, daily
transaction for the purchase of consumer goods, groceries, etc.)
performed at a merchant terminal. Additionally, loan requests may
also take the form of other transfers of value aside from fiat
currency, such as requests for cryptocurrency, credit towards a
future transaction, an exchange of tokens having value, and the
like.
[0112] Referring now to FIG. 22 an illustration of a lending pool
generator for generating lending pool smart contracts is described
in more detail. Each lender 1200, 1202, 1204 contributes 1206 to a
lending pool with conditions including the amount of money to lend,
duration of lending and expected returns. Lenders 1200, 1202, 1204
can have different conditions and may contribute to one or more
lending pools. A lending pool smart contract generator 1208 is used
to generate smart contracts 1210, 1212, 1214 which represent the
lending pools.
[0113] Referring now to FIG. 23 an illustration of a matching
engine for matching borrowers to lending pools is described in more
detail. Each borrower 1250, 1252, 1254, 1256 requests money with
conditions including the amount of money to borrow, duration for
which money is to be borrowed and acceptable rate of interest. A
matching engine 1258 matches the borrowers 1250, 1252, 1254, 1256
to lending pool smart contracts 1260, 1262, 1264 such that the
borrower level and pool level conditions are satisfied. A borrower
1250, 1252, 1254, 1256 may be matched to more than one lending
pool.
[0114] Referring now to FIG. 24 an illustration of feeding external
data to lending pool contracts using an oracle is described in more
detail. Lending pool and related smart contracts 1304 are deployed
on a blockchain network 1306. An oracle 1302 is used to feed in
external or dynamic information (such as exchange rates, market
value of collateral) to the lending pool smart contracts. The
oracle 1302 may obtain such information from external sources and
the web 1300.
[0115] Referring now to FIG. 25 an illustration of channels and
triggers for lending pools is described in more detail. Lending
pools 1324, 1326, 1328 comprising Lenders 1320 and distributing to
Borrowers 1330 can have channels 1332, 1334 between them for
transfer of pooled funds between the pools based on external
triggers 1322. Moving funds from one pool to another pool may be
required when a pool is not performing well and the high-level
(pool-level) and low-level (lender and borrower level) constraints
are not being satisfied. The P2P2P lending platform may monitor the
performance of each lending pool and generate triggers for transfer
of funds from one pool to another.
[0116] Referring now to FIG. 26 an illustration of the smart
contracts involved in a lending pool is described in more detail.
Each lender 1352 is represented by an individual smart contract
1358 in the lending pool 1350. Similarly, each borrower 1354 is
represented by an individual smart contract 1360 in the lending
pool 1350. The lender smart contracts 1358 link lenders 1352 to the
lending pool 1350 via the lending pool contract 1356. The borrower
smart contracts 1360 link borrowers 1354 to the pool lending 1350
via the lending pool contract 1356. There is no direct link between
the lenders 1352 and borrowers 1354 like traditional smart
contracts used in blockchain based peer-to-peer lending
solutions.
[0117] In current lending schemes (especially computer-implemented
lending schemes or blockchain based peer-to-peer lending schemes),
if there are a large number of investors in a lending pool, each
specifying an investment amount they would like to invest, the
rates they would like to receive in combination with time periods
(such as 2.3% over 3 months, or 2.2% over 6 months) and with
various exit strategies, and large number of borrowers specifying
various terms and repayment periods and early payoff options, the
following problems arise: [0118] Manual reconciliation is not
possible when the number of active and passive investors enter and
leave the pool. [0119] A scalable and secure solution is not
possible.
[0120] Abstracting the lenders and borrowers with "linked" smart
contracts in a lending pool solves the problems of manual
reconciliation and scalability. Additionally, this approach
provides the following benefits: [0121] Borrowers with good credit
may borrow at better rates and lend to other borrowers with bad
credit with the borrowed money at higher rates. [0122] A seamless
lending environment can be created with options to borrow or lend
at certain rates and offer these derivatives for trading as
well.
[0123] Referring now to FIG. 27 an illustration of pool-of-pools
comprised of multiple lending pools, is described in more detail.
Multiple lending pools can be clubbed together to create a
pool-of-pools. The pool-of-pools approach is beneficial for highly
volatile pools in which borrowers and lenders keep entering and
exiting and it is difficult to meet the high-level (pool-level) and
low-level (lender and borrower level) constraints. Combining
multiple pools into a pool-of-pools brings stability to the P2P2P
lending platform. A pool-of-pools approach may comprise a plurality
of lending pools 1402, 1404, 1406, 1408 that each interact with a
pool of pools 1400. Each of the plurality of lending pools 1402,
1404, 1406, 1408 may comprise borrower smart contracts with
respective borrowers 1412, 1420, 1424, 1428 and lender smart
contracts with respective lenders 1410, 1418, 1422, 1426.
Additionally, some borrowers 1416 and lenders 1414 may interact
directly with the pool of pools 1400.
[0124] Referring now to FIG. 28 an illustration of lending pool
smart contract structures and transactions is described in more
detail. A contract owner (or the lending platform) 1522 creates and
owns 1520 a lending pool contract 1500. The lending pool contract
1500 is created from an externally owned account (EOA) 1518 of the
contract owner (or the lending platform) 1522 when a create
contract transaction 1510 is performed by the EOA 1518 thereby
creating 1502 the lending pool contract 1500. Lenders 1524 use
their EOAs 1528 to send transactions 1532 to the lending pool
contract 1500. A lender 1524 can join 1506 a lending pool by
sending a joinPool transaction 1514. Borrowers 1526 use their EOAs
1530 to send transactions 1534 to the lending pool contract 1500. A
borrower 1526 can repay a loan 1508 taken from the lending pool by
sending a repayLoan transaction 1516.
[0125] Referring now to FIG. 29 an exemplary classification of
lending pools based on their risks and returns is described in more
detail. Lending pools are classified based on their risks and
returns. The lending pools with lower risk have lower returns and
the lending pools with higher risk have higher returns. The risk
level for a lending pool is computed based on the reputation and
credit scores of the borrowers and lenders linked to the pool. The
pools which lend money to borrowers with high credit scores usually
lend at low rates of interest as these loans are considered to be
safe. Similarly the pools which lend money to borrowers with low
credit scores usually lend at high rates of interest as these loans
are considered to be risky. In some embodiments, the loan risk may
be categorized as low, medium, and high, and the returns may also
be characterized as low, medium and high. This may result in
risk-reward categories of low risk-high returns 1600, medium
risk-high returns 1602, high risk-high returns 1604, low
risk-medium returns 1608, medium risk-medium returns 1618, high
risk-medium returns 1620, low risk-low returns 1612, medium
risk-low returns 1614, and high risk-low returns 1616. Most lending
pools will fall into one of low risk-low returns 1612, low
risk-medium returns 1608, medium risk-medium returns 1618, medium
risk-high returns 1602, and high risk-high returns 1604.
[0126] Referring now to FIG. 30 an illustration of an alliance of
merchants with interoperable loyalty points is described in more
detail. Customers 1150 and 1152 make payments 1154 at affiliated
merchant stores 1156 using nCash. The merchant payments are
processed 1158 by the nCash network 1160. Customer's receive
loyalty points that work at any merchant in the alliance or network
or affiliated merchants 1156. These loyalty points are
interoperable across all the merchants in the alliance and can be
applied towards a discount for the next purchase.
[0127] Referring now to FIG. 31 an illustration of a distributed
messaging framework, is described in more detail. The distributed
publish-subscribe messaging framework described here is referred to
as Bulleting Board Messaging Framework (BBMF) or "Bulletin Board".
The Bulletin Board Server 1678 manages Topics 1680, 1682. Bulletin
Board Clients can be Publisher/Producer Clients 1670, 1672 or
Consumer/Subscriber Clients 1688, 1690. The Publisher/Producer
Clients 1670, 1672 publish data or messages to Topics 1680, 1682.
Data pushed to the topics 1680, 1682 from the Publisher/Producer
Clients 1670, 1672 may originate from data sources 1650, which may
comprise smart contracts 1652, oracles 1654, logs 1656, sensors
1658, records 1660, databases 1662, streams 1664, and events 1668.
Consumer/Subscriber Clients 1688, 1690 consume data from the Topics
1680, 1682, receiving messages 1684, 1686 from the Bulletin Board
Server 1678. Bulletin Board Server 1678 supports a plug-in Message
Storage Backend 1692 to store and replay messages. The Message
Storage Backend 1692 persists the messages using two options: (1) a
Cloud Database or Cloud Storage 1694, (2) Decentralized Storage
Platform (such as IPFS or Swarm) 1698 with regular checkpointing of
message hashes to a Blockchain 1696. Messages in the Bulletin Board
can be either Ephemeral or Persistent. Ephemeral messages are not
stored by the Message Storage Backend. For Persistent messages
Time-to-Live (TTL) can be specified. The Producers and Consumers
support both Cloud and Blockchain protocols such as HTTP-REST or
Web3 for Ethereum. This allows existing Smart Contracts (such as
Solidity smart contracts) to publish and consume data to/from the
Bulletin board, and existing Oracles to feed-in data from the web
to the smart contracts through the Bulletin board. A smart contract
implemented in the Solidity language, for example, is a data source
which generates notifications in the form of Solidity events which
are published to the Bulletin Board server by a Publisher Client.
Solidity smart contracts require an external Publisher Client to
publish messages to the Bulletin board. Extensions to smart
contract languages such as Solidity may be implemented to support
Bulletin board APIs to publish data without the need for an
external publisher client. These extensions and/or stubs can be
through use of pragma directives that may be pre-processed by
pre-processors to generate suitable code for implementing the
interfaces to the bulletin board, or they could involve extensions
to the language itself to support global variable names. Topics are
managed in-memory with regular snapshots on the disk which are
later stored in the Message Storage Backend 1692. A compaction
process is defined for moving the messages in the snapshots to the
Message Storage Backend 1692 (Cloud and/or Blockchain). The
Bulletin Board itself may be implemented in part through use of a
cloud-based service and/or a blockchain and may also include
hardware accelerators (such as ASICs or FPGAs) and graphical
processing units (GPUs) to provide this high throughput low latency
service. Additional redundancy, authorization, and encryption
layers may also be provided in hardware and software using known
techniques for cloud and internet networks to secure the messages
and values stored from system failures or hacking attacks.
[0128] The BBMF is designed for high throughput and low latency
messaging. The Bulletin Board server 1678 can be deployed in a
cloud computing environment and scaled either vertically or
horizontally based on demand. In vertical scaling larger virtual
machine instance size (in terms of compute capacity, memory and
storage) is used for the Bulletin Board server. In horizontal
scaling multiple instances of the Bulletin Board server are
launched with each instance managing a subset of the topics managed
by the Bulletin Board.
[0129] BBMF supports both push/pull and publish/subscribe data
ingestion models and data delivery models. Furthermore, the data
delivery may be either at-least once delivery or exactly-once
delivery. BBMF can be implemented in hardware and software, using a
combination of servers, ASICs/FPGAs and GPUs as part of a
cloud-based or a locally configured computing system.
[0130] As Bulletin Board is a distributed messaging framework, a
trade-off exists between consistency and availability. This
trade-off is explained with the CAP Theorem, which states that
under partitioning, a distributed data system can either be
consistent or available but not both at the same time. Bulletin
Board adopts an eventually consistent model. In an eventually
consistent system, after an update operation is performed by a
writer, it is eventually seen by all the readers. When a read
operation is performed by a consumer, the response might not
reflect the results of a recently completed write operation.
[0131] The Bulletin Board messaging framework supports prioritized
processing of messages. The priority can be set in the message
header field. Various priority classes for messages can be defined
and specified in the priority header field. This priority
classification of messages is crucial for the Peer-to-Pool-Peer
(P2P2P) lending system when a large number of updates have to be
propagated to linked smart contracts in the lending system.
[0132] Referring now to FIG. 32 an illustration of the
consumer/subscriber actions supported in the publish-subscribe
messaging framework are described in more detail. For Consumers or
Subscribers 1708 various actions Rules & Triggers 1710 and
Actions 1712 can be defined. Rules & Triggers 1712 specify how
to filer and select data and trigger actions. The supported actions
1716 include Smart Contract Transaction 1718, Webhook Trigger 1720,
Log to External Data Store 1722, Email Notification 1724, SMS
Notification 1726, and Mobile Push Notification 1728. An action is
performed when a message 1706 matching a rule is received (for
example temperature>60 or ETH price<$500) from the Bulletin
Board Server 1700, being related to one of the Topics 1702, 1704
managed by the Bulletin Board Server 1700. The message may be
transmitted to the Consumer or Subscriber Client 1708 by any means
or method known in the art, including, but not limited to,
HTTP/REST applications and WebSocket. The smart contract
transaction action is particularly useful for the P2P2P lending
system described above where a large number of linked smart
contracts (such as smart contracts in a lending pool) can be
executed when a message notifying a change in the lending
conditions is received.
[0133] Referring now to FIG. 33 an illustration of a smart contract
data source that uses an external publisher client to publish
messages to the publish-subscribe messaging framework is described
in more detail. A smart contract data source 1800 such as a
Solidity smart contract generates notifications or events 1802. A
publisher/producer client 1804 watches for the notifications or
events generated by the smart contract 1800. When a notification or
event is generated, the messages are published 1806 to the topics
1810, 1812 managed by the Bulletin Board 1808. These messages are
delivered 1814 to the consumer/subscriber client 1816 which has
subscribed to the topics 1810, 1812. The consumer/subscriber client
1816 has a smart contract transaction action configured which sends
transactions 1818, 1820 to the linked smart contracts 1822, 1824 on
receiving the messages.
[0134] Referring now to FIG. 34 an illustration of a smart contract
data source that uses an integrated publisher client to publish
messages to the publish-subscribe messaging framework, is described
in more detail. A smart contract data source with integrated
publisher/producer client 1850 generates notifications or events.
The notifications or events are published as messages 1852 to the
topics 1856, 1858 managed by the Bulletin Board 1854. These
messages are delivered 1860 to the consumer/subscriber client 1862
which has subscribed to the topics 1856, 1858. The
consumer/subscriber client 1862 has a smart contract transaction
action configured which sends transactions 1864, 1866 to the linked
smart contracts 1868, 1870 on receiving the messages.
[0135] Referring now to FIG. 35 an illustration of the message
format for the publish-subscribe messaging framework is described
in more detail. The Message Type field 1750 defines the type of the
message. Supported message types in the Bulletin Board framework
are as follows: [0136] CONNECT: A CONNECT message is sent by a
client (producer or consumer) to connect to the server. [0137]
DISCONNECT: A DISCONNECT message is sent by a client to disconnect
from the server. [0138] PUBLISH: Used to publish a new message
[0139] SUBSCRIBE: Used to subscribe to a topic managed by the
Bulletin Board [0140] UNSUBSCRIBE: Used to unsubscribe from a topic
[0141] PINGREQUEST: Used to send a ping request to the server
[0142] PINGRESPONSE: Used to respond to a ping request [0143]
DATAREQUEST: Used to request a message or data item [0144]
DATARESPONSE: Used to respond to a request for a message or data
item.
[0145] The Data Payload field 1752 includes the message as a JSON
data payload. The message may be signed by the sender and/or
encrypted. The Topics field 1754 includes a list of topics to which
the message is published. The Headers field 1756 includes headers
such as: [0146] Sender or receiver identity [0147] Message
signature [0148] QoS Level [0149] Priority [0150] Persistent or
Ephemeral message [0151] Additional flags to help in processing of
message
[0152] The Time-to-Live (TTL) field 1758 is used to specify the
validity or life of the message. The Nonce field 1760 is an integer
value which can be used to prove that a given amount of work was
done in composing the message.
[0153] Referring now to FIG. 36 an illustration of a blockchain
checkpointing approach in the publish-subscribe messaging
framework, is described in more detail. When using Blockchain and
Decentralized Storage Platform (IPFS or Swarm) based Message
Storage Backend, the messages 1780 are hashed 1782 and are added to
a Merkle Tree 1784. The root hash 1786 of the Merkle Tree 1784
(after every N messages) is recorded on the Blockchain 1788. This
ensures messages cannot be tampered with later.
[0154] Referring now to FIG. 37 an illustration of a global
variable name system being updated by a consumer of the
publish-subscribe messaging framework, is described in more detail.
The Global Variable Name System (GVNS) 1916 maintains records of
global variables and the owners and resolvers for the global
variables. Data sources 1900 such as a smart contract, oracle, log,
sensor, record, database, stream or event, produce data or
notifications which are sent to a publisher/producer client 1902.
The publisher/producer client 1902 publishes the data or
notification as a message 1904 to one or more topics 1908, 1910
managed by the Bulletin Board server 1906. The consumer/subscriber
client 1914 receives the messages 1912 and updates the value of
global variables registered in the GVNS 1916. Smart contracts 1918,
1920, 1922 reference the global variable registered in the GVNS
1916.
[0155] Referring now to FIG. 38 an illustration of the architecture
of a global variable name system, is described in more detail. The
Global Variable Name System (GVNS) 1950 comprises Registrar 1952,
Registry 1954 and Resolver 1956 components. The Registrar 1952 is
responsible for registering new variable names, updating the
resolver for a variable name, and transferring the ownership of a
variable. The Registry 1954 is responsible for recording the owner
and resolver of a variable name, and returning the resolver for a
variable name. The Resolver 1956 is responsible for resolving a
variable name to a value and updating the value of a registered
variable. The steps involved in registering a global variable in
the GVNS 1950, updating the variable and retrieving the current
value of the variable are explained as follows. At step-1 1958 a
user 1980 sends a request (through an externally owned account 1978
or a smart contract 1976) to register a new global variable name
(for example, ncash.supply) to the Registrar 1952. At step-2 1960,
the Registrar 1952 sets the owner and resolver for the variable in
the Registry 1954. At step-3 1970, a consumer/subscriber client
1972 or a smart contract 1974 sends a request to update the value
of the global variable to the Resolver 1956. At step-4 1962, a
smart contract 1966 requests the value of the global variable from
the Registry 1954. At step-5 1964, the Registry 1954 retrieves the
Resolver 1956 for the variable. At step-6 1968, the Resolver 1956
returns the value of the global variable.
[0156] Referring now to FIG. 39 an illustration of global variable
sharing across smart contracts is described in more detail. The
Lending Pool smart contract 2004, Lending Request smart contract
2002 and Loan smart contract 2006 are linked smart contracts in a
Peer-to-Pool-Peer (P2P2P) lending system that are used in loan
making and loan servicing processes. The Lending Request smart
contract 2002 is used in the loan making process. Borrowers send
lending requests to the lending system and a Lending Request smart
contract is created for each lending request. The Lending Pool
smart contract 2004 is used to manage a lending pool. When the
lending system matches a lending request to a lending pool, a new
Loan smart contract 2006 is created. The Loan smart contract 2006
manages the loan servicing aspects of a loan from the time the loan
is disbursed until the loan is paid off. The Loan smart contract
2006 captures the loan details such as loan principal, loan
interest rate, address of lending pool contract from where the loan
is disbursed as state variables. Loan smart contract 2006 also
registers global variables 2042 such as for the loan amount repaid
(loanAmountRepaid) and loan status (loanStatus). The Lending Pool
smart contract 2004 and Lending Request smart contract 2002 have
global variables 2022, 2012 which are registered 2010, 2008 with
the Global Variable Name Systems (GVNS) 2000
(lendingPool_AmountRaised, lendingPool_numLenders,
lendingRequest_AmountRequested). These global variables are
referenced 2032 in the Loan smart contract 2006.
[0157] Each of the smart contracts 2002, 2004 and 2006 have state
variables 2014, 2024, 2034, functions 2016, 2026, 2036, modifiers
2018, 2028, 2038, and events 2020, 2030, 2040, which are existing
elements/types/constructs in the Solidity smart contracts language.
Support for global variables which are shared across multiple smart
contracts through GVNS 2000 within Solidity smart contracts
language, is added through extensions to the Solidity language
specification. Furthermore, extensions are done within the Ethereum
Virtual Machine (EVM) which is the runtime environment for smart
contracts in Ethereum to add support for global variables shared
through GVNS 2000. While Solidity and Ethereum have support for a
limited set of global variables that provide information about the
blockchain (such as block.coinbase, block.difficulty,
block.gaslimit, block.number, block.blockhash, block.timestamp,
msg.data, msg.gas, msg.sender, msg.value, tx.gasprice, tx.origin,
this.balance, addr.balance), it is not possible for two or more
linked smart contracts to share global variables. This additional
support for global variables is enabled by the GVNS 2000,
extensions to the Solidity language specification and extensions to
the Ethereum Virtual Machine (EVM). The global variable support is
crucial for linked smart contracts (such as in a P2P2P lending
system) to work.
[0158] The BBMF when used in combination with GVNS could provide
information to an "analytics engine" as to the number of updates of
the global variables and their type, and also to "advertising
engines" as to the global variables referenced and their types.
[0159] Referring now to FIG. 40 an exemplary implementation of a
Bulletin Board Publisher/Producer client and Consumer/Subscriber
client is described in more detail. In the Publisher/Producer
client implementation an instance of the Bulletin Board client
class is created. The connect( ) method of the client class is used
to establish a connect to the Bulletin Board server by passing the
Bulletin Board server address, clientID and client secret. The
publish( ) method of the client class is used to publish a message
to the Bulletin Board server. The message object published to the
Bulletin Board server contains the list of topics, data payload,
headers, time-to-live and nonce fields. In the Consumer/Subscriber
Client implementation, subscribe( ) method of the client class is
used to subscribe to all or selected topics on the Bulletin Board
server. A callback function on_message( ) is defined which is
executed every time a new message is delivered.
[0160] Referring now to FIG. 41 an exemplary interface of the nCash
mobile application is described in more detail. The exemplary
interface shows options to buy coins, send coins, receive coins,
pay coins at a merchant, sell or withdraw coins, chat and transact
with contacts, view list of transactions, loans and settings
options. The customer's account details such as account number,
name and account balance is also shown.
[0161] Referring now to FIG. 42 an exemplary interface of the nCash
mobile application showing peer-to-peer lending options is
described in more detail. A customer is eligible to request loans
after completing the lending profile that includes customer's
financial and education information. Customer can view the nCash
credit score from the mobile application. Borrowing peers
(borrowers), can create new loan requests, view the status of
existing loan requests, view loan offers received from lending
peers (lenders) for the loan requests, and repay a loan. Lending
peers (lenders) can view open loan requests submitted by all
borrowing peers (borrowers) on the network, search for specific
loan requests by date range or loan request ID, send loan offers
for the loan requests, and release funds for accepted loan
offers.
[0162] Referring now to FIG. 43 an exemplary interface of the nCash
mobile application showing different types of transactions is
described in more detail. The transactions involved are of
following types: [0163] Transaction for buying new coins by paying
in fiat currency (such as USD) with credit/debit card or ACH bank
transfer [0164] Transaction for buying new coins by paying in
cryptocurrency (such as Bitcoin) [0165] Transaction for selling
coins and withdraw coins to a linked bank account [0166]
Transaction for transferring coins to another user [0167]
Transaction for a cashback received on availing a cashback offer.
[0168] Transaction for coins received on claiming a voucher
[0169] Referring now to FIG. 44 an exemplary interface of the nCash
mobile application showing chats and payments interface is
described in more detail. The chats and transactions interface
allows two customers to chat with each other and send or request
payments. A payment request received by a user can be approved or
declined from the chats and transactions interface itself.
[0170] Referring now to FIG. 45 an illustration of the nCash mobile
application features for different types of accounts is
depicted.
[0171] All of the above-described methods are performable on
computerized systems, such systems comprising a processor, a data
store (such as memory) positioned in communication with the
processor, and a network communication device position in
communication with the processor and operable to communicate across
a network, as are all known in the art.
[0172] Some of the illustrative aspects of the present invention
may be advantageous in solving the problems herein described and
other problems not discussed which are discoverable by a skilled
artisan.
[0173] While the above description contains much specificity, these
should not be construed as limitations on the scope of any
embodiment, but as exemplifications of the presented embodiments
thereof. Many other ramifications and variations are possible
within the teachings of the various embodiments. While the
invention has been described with reference to exemplary
embodiments, it will be understood by those skilled in the art that
various changes may be made and equivalents may be substituted for
elements thereof without departing from the scope of the invention.
In addition, many modifications may be made to adapt a particular
situation or material to the teachings of the invention without
departing from the essential scope thereof. Therefore, it is
intended that the invention not be limited to the particular
embodiment disclosed as the best or only mode contemplated for
carrying out this invention, but that the invention will include
all embodiments falling within the scope of the appended claims.
Also, in the drawings and the description, there have been
disclosed exemplary embodiments of the invention and, although
specific terms may have been employed, they are unless otherwise
stated used in a generic and descriptive sense only and not for
purposes of limitation, the scope of the invention therefore not
being so limited. Moreover, the use of the terms first, second,
etc. do not denote any order or importance, but rather the terms
first, second, etc. are used to distinguish one element from
another. Furthermore, the use of the terms a, an, etc. do not
denote a limitation of quantity, but rather denote the presence of
at least one of the referenced item.
[0174] Thus the scope of the invention should be determined by the
appended claims and their legal equivalents, and not by the
examples given.
* * * * *