U.S. patent application number 17/536764 was filed with the patent office on 2022-03-17 for blockchain based account funding and distribution.
The applicant listed for this patent is STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY. Invention is credited to Jacob J. Alt, Eric Bellas, Shawn M. Call, Greg Hayes, Robert Alpine Jennings, Vicki King, Melinda Teresa Magerkurth, Amber Nelson-Wolfe, Charles H. Roscow, Scott Shoop, Jaime Skaggs, Shyam Tummala.
Application Number | 20220084027 17/536764 |
Document ID | / |
Family ID | 1000005996788 |
Filed Date | 2022-03-17 |
United States Patent
Application |
20220084027 |
Kind Code |
A1 |
Alt; Jacob J. ; et
al. |
March 17, 2022 |
BLOCKCHAIN BASED ACCOUNT FUNDING AND DISTRIBUTION
Abstract
The present methods and systems relate to using and accessing
data stored in a blockchain, and in particular, interacting with
the blockchain and users via smart contracts to handle account
funding and distribution methods. The methods and systems include
receiving a transaction from a participant, and verifying the
transaction, such as by accessing a smart contract stored on the
blockchain and checking a set of parameters against a set of
conditions stored in the smart contract. Depending on whether the
set of parameters satisfy the conditions, the results may be
communicated to participants about the success or failure of the
transaction.
Inventors: |
Alt; Jacob J.; (Downs,
IL) ; Bellas; Eric; (Bloomington, IL) ;
Skaggs; Jaime; (Chenoa, IL) ; Call; Shawn M.;
(Bloomington, IL) ; Magerkurth; Melinda Teresa;
(Utica, IL) ; King; Vicki; (Bloomington, IL)
; Roscow; Charles H.; (Bloomington, IL) ; Shoop;
Scott; (Heyworth, IL) ; Hayes; Greg;
(Bloomington, IL) ; Jennings; Robert Alpine;
(Bloomington, IL) ; Nelson-Wolfe; Amber;
(Bloomington, IL) ; Tummala; Shyam; (Bloomington,
IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY |
Bloomington |
IL |
US |
|
|
Family ID: |
1000005996788 |
Appl. No.: |
17/536764 |
Filed: |
November 29, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16895797 |
Jun 8, 2020 |
|
|
|
17536764 |
|
|
|
|
15878007 |
Jan 23, 2018 |
10861015 |
|
|
16895797 |
|
|
|
|
62532102 |
Jul 13, 2017 |
|
|
|
62532072 |
Jul 13, 2017 |
|
|
|
62532089 |
Jul 13, 2017 |
|
|
|
62528806 |
Jul 5, 2017 |
|
|
|
62528791 |
Jul 5, 2017 |
|
|
|
62523523 |
Jun 22, 2017 |
|
|
|
62520708 |
Jun 16, 2017 |
|
|
|
62520648 |
Jun 16, 2017 |
|
|
|
62520376 |
Jun 15, 2017 |
|
|
|
62520401 |
Jun 15, 2017 |
|
|
|
62450441 |
Jan 25, 2017 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/401 20130101;
H04L 2209/56 20130101; H04L 2209/38 20130101; H04L 9/3236 20130101;
G06F 21/645 20130101 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40; H04L 9/32 20060101 H04L009/32; G06F 21/64 20060101
G06F021/64 |
Claims
1. A computer-implemented method for performing actions designated
in smart contracts stored on a blockchain maintained by a plurality
of participants, based upon notification of a person's death, the
method comprising: receiving, at one or more processors coupled
with a network interface, at least one death registry notification,
wherein one participant of the plurality of participants that
maintains the blockchain is an insurance provider that supplied a
life insurance policy; sending the notification to a smart contract
stored at an address on the blockchain; verifying, at the one or
more processors, the death registry notification and a set of
personal information of the notification, wherein verifying the
death registry notification includes requesting, at the one or more
processors, verification of the death registry notification and the
set of personal information from an agency outside the plurality of
participants that maintains the blockchain; retrieving from the
blockchain, at the one or more processors, an insurance policy
document associated with a person indicated in the set of personal
information; generating, at the one or more processors, a death
registry action based upon the set of documents, the set of
personal information, and the death registry notification;
checking, at the one or more processors, the death registry action
against the smart contract stored on the blockchain, wherein the
set of documents has a set of conditions; determining, at the one
or more processors, that the death registry action satisfies the
set of conditions based on a comparison of the set of conditions
against the set of requirements stored on the smart contract; and
executing, at the one or more processors, the death registry action
in response to the determination that the death registry action
satisfies the set of conditions by initiating disbursement of funds
as indicated by the insurance policy document.
2. The computer-implemented method of claim 1, wherein receiving
the death registry notification further comprises: receiving, at
the one or more processors coupled with the network interface, the
death registry notification from at least one of participant that
functions as an official custodian of death registry
notifications.
3. The computer-implemented method of claim 1, wherein the set of
personal information includes the person's date of death, and any
known beneficiaries for the person.
4. The computer-implemented method of claim 1, wherein the
notification is generated by a government agency informed by a
healthcare facility.
5. The computer-implemented method of claim 1, the set of personal
information includes the person's name, and date of birth.
6. The computer-implemented method of claim 1, wherein the
generating a death registry action further comprises: analyzing, at
the one or more processors, the set of documents, the set of
personal information, and the death registry notification to
determine the death registry action to take.
7. The computer-implemented method of claim 1, wherein the checking
includes comparing, at the one or more processors, the set of
conditions against a set of requirements stored in the smart
contract, wherein the set of conditions includes a payment history
of the life insurance policy, and the set of requirements stored in
the smart contract includes a payment history minimum
condition.
8. The computer-implemented method of claim 1, wherein executing
the death registry action further comprises: transmitting, at the
one or more processors coupled with the network interface, a
notification of the fund disbursement to a set of fund
beneficiaries; and transmitting, at the one or more processors
coupled with the network interface, a transaction indicating that
the funds have been dispersed in accordance with the death registry
action.
9. The computer-implemented method of claim 1, further comprising:
receiving, at the one or more processors coupled with the network
interface, a block of transactions representative of death registry
actions; verifying, at the one or more processors, the block of
transactions; transmitting, at the one or more processors coupled
with the network interface, the block of transactions to at least
one other participant; and adding, at a memory coupled with the one
or more processors, the block of transactions to a copy of the
blockchain.
10. A computer-implemented method for performing actions designated
in smart contracts stored on a blockchain maintained by a plurality
of participants, based upon notification of a person's death, the
method comprising: receiving, at a one or more processors coupled
with a network interface, at least one death registry notification,
wherein one participant of the plurality of participants that
maintains the blockchain is an insurance provider that supplied a
life insurance policy; sending the notification to a smart contract
stored at an address on the blockchain; verifying, at the one or
more processors, the death registry notification and a set of
personal information of the notification, wherein verifying the
death registry notification includes requesting, at the one or more
processors, verification of the death registry notification and the
set of personal information from an agency outside the plurality of
participants that maintains the blockchain; retrieving from the
blockchain, at the one or more processors, an insurance policy
document associated with a person indicated in the set of personal
information; generating, at the one or more processors, a death
registry action based upon the set of documents, the set of
personal information, and the death registry notification;
checking, at the one or more processors, the death registry action
against the smart contract stored on the blockchain, wherein the
set of documents has a set of conditions; determining, at the one
or more processors, that the death registry action satisfies the
set of conditions based on a comparison of the set of conditions
against the set of requirements stored on the smart contract;
executing, at the one or more processors, the death registry action
in response to the determination that the death registry action
satisfies the set of conditions by initiating disbursement of funds
as indicated by the insurance policy document; generating, at the
one or more processors, a transaction containing the death registry
action; adding, at the one or more processors, the transaction to a
block of transactions; generating, at the one or more processors, a
solution to a cryptographic puzzle for the block of transactions;
transmitting, at the one or more processors coupled with the
network interface, the block of transactions and the solution for
the cryptographic puzzle to at least one other participant; and
transmitting, via the one or more processors coupled with the
network interface, the transaction to the plurality of participants
that maintains the blockchain.
11. The computer-implemented method of claim 10, wherein the
notification is generated by a government agency informed by a
healthcare facility.
12. The computer-implemented method of claim 10, wherein generating
a death registry action further comprises: analyzing, at the one or
more processors, the set of documents, the set of personal
information, and the death registry notification to determine the
death registry action to take.
13. The computer-implemented method of claim 10, wherein executing
the death registry action further comprises: transmitting, at the
one or more processors coupled with the network interface, a
notification of the fund disbursement to a set of fund
beneficiaries; and transmitting, at the one or more processors
coupled with the network interface, a transaction indicating that
the funds have been dispersed in accordance with the death registry
action.
14. A computer system for performing actions designated in smart
contracts stored on a blockchain maintained by a plurality of
participants, based upon notification of a person's death, and
wherein one participant of the plurality of participants that
maintains the blockchain is an insurance provider that supplied a
life insurance policy, and wherein the computer system comprises: a
memory configured to store non-transitory computer executable
instructions; and one or more processors configured to interface
with the memory, wherein the one or more processors are configured
to execute the non-transitory computer executable instructions to
cause the one or more processors to: receive at least one death
registry notification; send the notification to a smart contract
stored at an address on the blockchain; validate the death registry
notification and a set of personal information of the notification,
wherein validation of the death registry notification includes
requesting verification of the death registry notification and the
set of personal information from an agency outside the plurality of
participants that maintains the blockchain; retrieve from the
blockchain, an insurance policy document associated with a person
indicated in the set of personal information; generate a death
registry action based upon the set of documents, the set of
personal information, and the death registry notification; check
the death registry action against the smart contract stored on the
blockchain, wherein the set of documents has a set of conditions;
and execute the death registry action when the death registry
action satisfies the set of conditions by initiating disbursement
of funds as indicated by the insurance policy document.
15. The system of claim 14, wherein the non-transitory computer
executable instructions to receive the notification further
comprise instructions to receive the notification from a government
agency informed by a healthcare facility.
16. The system of claim 14, wherein the set of personal information
includes the person's name, and date of birth.
17. The system of claim 14, wherein non-transitory computer
executable instructions further comprise instructions to: analyze
the set of documents, the set of personal information, and the
death registry notification to determine the death registry action
to take.
18. The system of claim 14, wherein non-transitory computer
executable instructions further comprise instructions to: transmit
a notification of the fund disbursement to a set of fund
beneficiaries; and transmit a transaction indicating that the funds
have been dispersed in accordance with the death registry
action.
19. The system of claim 14, wherein non-transitory computer
executable instructions further comprise instructions to: receive a
block of transactions representative of death registry actions;
verify the block of transactions; transmit the block of
transactions to at least one other participant; and add the block
of transactions to a copy of the blockchain.
20. The system of claim 14, wherein non-transitory computer
executable instructions further comprise instructions to: analyze
the set of documents by identifying a lienholder; and execute a
priority process of the smart contract by recalculating a
settlement value for the identified lienholder, and distributing
the recalculated settlement value to the identified lienholder.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to Non-Provisional
application Ser. No. 16/895,797, entitled "Blockchain Based Account
Funding and Distribution," filed Jun. 8, 2020, which claims
priority to Non-Provisional application Ser. No. 15/878,007,
entitled "Blockchain Based Account Funding and Distribution," filed
Jan. 23, 2018, which claims priority to: (1) Provisional
Application No. 62/450,441, entitled "Using Blockchain for Banking,
Asset, and Identity Services," filed Jan. 25, 2017, (2) Provisional
Application No. 62/520,401, entitled "Blockchain Based Account
Funding and Distribution," filed Jun. 15, 2017, (3) Provisional
Application No. 62/520,376, entitled "Blockchain Based Banking
Identity Authentication," filed Jun. 15, 2017, (4) Provisional
Application No. 62/520,648, entitled "Blockchain Based Card
Activation," filed Jun. 16, 2017, (5) Provisional Application No.
62/520,708, entitled "Blockchain Based Passing Registry Actions,"
filed Jun. 16, 2017, (6) Provisional Application No. 62/523,523,
entitled "Blockchain Based Asset Access," filed Jun. 22, 2017, (7)
Provisional Application No. 62/528,791, entitled "Blockchain Based
Lien Perfection," filed Jul. 5, 2017, (8) Provisional Application
No. 62/528,806, entitled "Blockchain Based Settlement Processes,"
filed Jul. 5, 2017, (9) Provisional Application No. 62/532,072,
entitled "Blockchain Based Contractor Ratings," filed Jul. 13,
2017, (10) Provisional Application No. 62/532,089, entitled
"Blockchain Based Customer Records," filed Jul. 13, 2017, and (11)
Provisional Application No. 62/532,102, entitled "Blockchain Based
Associate Information and Licensing," filed Jul. 13, 2017, each of
which is incorporated herein by reference in its entirety.
TECHNICAL FIELD
[0002] The present disclosure relates to using and accessing data
stored in a blockchain. In particular, interacting with the
blockchain and users of the blockchain via smart contracts, and
protocols to perform account funding and distribution related
activities.
BACKGROUND
[0003] In the business world, an interaction between a business and
a customer, or the business and another business, typically
requires validation of one or more pieces of information before a
transaction can take place. This validation is often achieved by
the participants involved in the interaction contacting a central
authority that is a trusted source of truth for the particular
piece of information. The central authority may then validate, or
not validate the particular piece of information and communicate
its findings to the participants. Based upon the validation, or
lack of validation, a consensus among the participants is formed
and assuming the information is valid the transaction between the
participants may take place, and subsequently be recorded. Similar
issues arise between citizens and their governments, and businesses
and governments.
[0004] Traditionally, businesses, customers, and central
authorities have stored information related to transactions, and
records of transactions, in databases, or ledgers which have been
used in accounting to track transactions and information related to
those transactions. Often these databases or ledgers held by the
participants must be reconciled to achieve consensus as to the
validity of the information stored in the databases and ledgers.
Alternatively, as described above the central authority may be
responsible for determining the validity of information stored in a
database or a ledger and functioning as an arbiter of consensus for
interested parties.
[0005] A blockchain is a new way of achieving a distributed
consensus on the validity or invalidity of information. As opposed
to using a central authority, a blockchain is a distributed
database or ledger, in which a transactional record is maintained
at each node of a peer to peer network. Commonly, the distributed
ledger is comprised of groupings of transactions bundled together
into a "block." When a change to the distributed ledger is made
(e.g., when a new transaction and/or block is created), each node
must form a consensus as to how the change is integrated into the
distributed ledger. Upon consensus, the agreed upon change is
pushed out to each node so that each node maintains an identical
copy of the updated distributed ledger. Any change that does not
achieve a consensus is ignored. Accordingly, unlike a traditional
system which uses a central authority, a single party cannot
unilaterally alter the distributed ledger. This inability to modify
past transactions lead to blockchains being generally described as
trusted, secure, and/or immutable.
[0006] Blockchains are typically deployed in an open,
decentralized, and permissionless manner meaning that any party may
view information, submit new information, or join the blockchain as
a node responsible for confirming information. This open,
decentralized, and permissionless approach to a blockchain has
limitations. As an example, these blockchains may not be good
candidates for interactions that require information to be kept
private, or for interactions that require all participants to be
vetted prior to their participation.
BRIEF SUMMARY
[0007] In one aspect, a computer-implemented method for account
management using smart contracts stored on a blockchain maintained
by a plurality of participants may be provided. The method may
include, via one or more processors, servers, and/or transceivers,
(1) receiving (such as via wireless communication or data
transmission over one or more radio frequency links or
communication channels) at least one transaction from at least one
participant, wherein the at least one transaction has a set of
parameters; (2) verifying the at least one transaction, wherein
verifying includes accessing a smart contract stored on the
blockchain and checking the set of parameters against a set of
conditions stored in the smart contract; and (3) when the set of
parameters satisfy the set of conditions, (i) indicating a change
in a balance for the at least one participant; and (ii) generating
and transmitting (such as via wireless communication or data
transmission over one or more radio frequency links or
communication channels) a confirmation to the at least one
participant that the transaction has been approved; and/or (4) when
the set of parameters do not satisfy the set of conditions,
generating and transmitting (such as via wireless communication or
data transmission over one or more radio frequency links or
communication channels) a rejection to the at least one participant
that the transaction has been rejected. The method may include
additional, less, or alternate actions, including those discussed
elsewhere herein.
[0008] In another aspect, a computer-implemented method for account
funding and distribution using smart contracts stored on a
blockchain maintained by a plurality of participants may be
provided. The method may include, via one or more processors,
servers, and/or transceivers, (1) receiving (such as via wireless
communication or data transmission over one or more radio frequency
links or communication channels) a request for funds from at least
one participant, wherein the request for funds has a set of
parameters; (2) verifying the request for funds, wherein verifying
includes accessing a smart contract stored on the blockchain and
checking the set of parameters against a set of conditions stored
in the smart contract; and (3) when the set of parameters satisfy
the set of conditions, (i) satisfying the request for funds by
transmitting the corresponding amount of funds to the at least one
participant; (ii) generating and transmitting (such as via wireless
communication or data transmission over one or more radio frequency
links or communication channels) a confirmation to the at least one
participant that the request for funds has been approved; (iii)
generating a block of transactions representative of requests for
funds containing the at least one request for funds, and/or (iv)
transmitting (such as via wireless communication or data
transmission over one or more radio frequency links or
communication channels) the block of transactions to at least one
participant; and/or (4) when the set of parameters do not satisfy
the set of conditions, generating and transmitting (such as via
wireless communication or data transmission over one or more radio
frequency links or communication channels) a rejection to the at
least one participant that the request for funds has been rejected.
The method may include additional, less, or alternate actions,
including those discussed elsewhere herein.
[0009] In yet another aspect, a computer system for account funding
and distribution using smart contracts stored on a blockchain
maintained by a plurality of participants may be provided. The
computer system may include a memory configured to store
non-transitory computer executable instructions; and a processor
(and an associated transceiver) configured to interface with the
memory, wherein the processor is configured to execute
non-transitory computer executable instructions. The non-transitory
computer executable instructions to cause the processor and/or
associated transceiver to: (1) receive (such as via wireless
communication or data transmission over one or more radio frequency
links or communication channels) at least one request for funds
from at least one participant, wherein the at least one transaction
has a set of parameters; (2) validate the request for funds,
wherein validate includes accessing a smart contract stored on the
blockchain and checking the set of parameters against a set of
conditions stored in the smart contract; and (3) when the set of
parameters satisfy the set of conditions, (i) indicate a change in
a fund balance for the at least one participant; and (ii) generate
and transmit (such as via wireless communication or data
transmission over one or more radio frequency links or
communication channels) a confirmation to the at least one
participant that the transaction has been approved; and/or (4) when
the set of parameters do not satisfy the set of conditions,
generate and transmit (such as via wireless communication or data
transmission over one or more radio frequency links or
communication channels) a rejection to the at least one participant
that the transaction has been rejected. The system may include
additional, less, or alternate functionality, including that
discussed elsewhere herein.
[0010] Advantages will become more apparent to those of ordinary
skill in the art from the following description of the preferred
aspects, which have been shown and described by way of
illustration. As will be realized, the present aspects may be
capable of other and different aspects, and their details are
capable of modification in various respects. Accordingly, the
drawings and description are to be regarded as illustrative in
nature and not as restrictive
BRIEF DESCRIPTION OF DRAWINGS
[0011] The figures described below depict various aspects of the
system and methods disclosed herein. It should be understood that
each figure depicts an embodiment of a particular aspect of the
disclosed system and methods, and that each of the figures is
intended to accord with a possible embodiment thereof. Further,
wherever possible, the following description refers to the
reference numerals included in the following figures, in which
features depicted in multiple figures are designated with
consistent reference numerals.
[0012] There are shown in the drawings arrangements which are
presently discussed, it being understood, however, that the present
embodiments are not limited to the precise arrangements and
instrumentalities shown, wherein:
[0013] FIG. 1A depicts an exemplary database system 100 in
accordance with one aspect of the present disclosure;
[0014] FIG. 1B depicts an exemplary distributed ledger system 112
in accordance with one aspect of the present disclosure;
[0015] FIG. 2A depicts an exemplary transaction flow 200 in
accordance with one aspect of the present disclosure;
[0016] FIG. 2B depicts an exemplary block propagation 210 in
accordance with one aspect of the present disclosure;
[0017] FIG. 3 depicts an exemplary sequence diagram 300 in
accordance with one aspect of the present disclosure;
[0018] FIG. 4 depicts an exemplary node 400 in accordance with one
aspect of the present disclosure;
[0019] FIG. 5 depicts an exemplary blockchain 500 in accordance
with one aspect of the present disclosure;
[0020] FIG. 6 depicts an exemplary flow diagram 600 associated with
one aspect of the present disclosure;
[0021] FIG. 7 depicts an exemplary flow diagram 700 associated with
one aspect of the present disclosure;
[0022] FIG. 8 depicts an exemplary flow diagram 800 associated with
one aspect of the present disclosure;
[0023] FIG. 9 depicts an exemplary flow diagram 900 associated with
one aspect of the present disclosure;
[0024] FIG. 10 depicts an exemplary flow diagram 1000 associated
with one aspect of the present disclosure;
[0025] FIG. 11 depicts an exemplary flow diagram 1100 associated
with one aspect of the present disclosure;
[0026] FIG. 12 depicts an exemplary flow diagram 1200 associated
with one aspect of the present disclosure;
[0027] FIG. 13 depicts an exemplary flow diagram 1300 associated
with one aspect of the present disclosure;
[0028] FIG. 14 depicts an exemplary flow diagram 1400 associated
with one aspect of the present disclosure; and
[0029] FIG. 15 depicts an exemplary flow diagram 1500 associated
with one aspect of the present disclosure.
[0030] As stated, the Figures depict aspects of the present
embodiments for purposes of illustration only. One skilled in the
art will readily recognize from the following discussion that
alternate aspects of the structures and methods illustrated herein
may be employed without departing from the principles of the
invention described herein.
DETAILED DESCRIPTION
[0031] The present embodiments relate to, inter alia, systems and
methods for using a blockchain to perform services related to
banking, identity management, and insurance applications. The
systems and methods described herein allow for using a blockchain
which gives the option for private information, and permissioned
participants in the blockchain. In particular, the systems and
methods allow for a distributed consensus amongst businesses,
consumers, and authorities, as to the validity of information and
transactions stored on the blockchain. The businesses, authorities,
and consumers may all be considered participants in the blockchain
network. For example, businesses (e.g., banks, financial
institutions, insurers), and their customers, as well as
regulators, may all be participants in the blockchain network,
which may be open and permissionless, or closed and permissioned.
Each of these participants may maintain nodes that are part of the
blockchain network, but may also maintain their own systems and
networks that may interface with the blockchain network.
[0032] Some exemplary, but not limiting, applications that may take
advantage of the disclosed systems and methods include specific
applications directed to banking, mutual funds, and insurance.
These examples relate to problems surrounding money transfers,
digital identities, and collective reporting. Specifically, such
applications may be: identity authentication, account funding and
distribution, card activation, actions trigged by death registry,
using and accessing asset data lien perfection obtaining settlement
values contractor ratings/evaluations single view of customer's
products, associate licensing, using and accessing user data,
blockchain based payments, interest validation, industry reporting,
agent sales data fund transfers, unclaimed property, auditing and
compliance, policy delivery and interaction, and exercising riders
and form/rate filing.
[0033] The above listed examples, and disclosed systems and
methods, may use an application of distributed ledgers, where each
new block may be cryptographically linked to the previous block in
order to form a "blockchain." More particularly, to create a new
block, each transaction within a block may be assigned a hash value
(i.e., an output of a cryptographic hash function, such as SHA-256
or MD5). These hash values may then be combined together utilizing
cryptographic techniques (e.g., a Merkle Tree) to generate a hash
value representative of the entire new block, and consequently the
transactions stored in the block. This hash value may then be
combined with the hash value of the previous block to form a hash
value included in the header of the new block, thereby
cryptographically linking the new block to the blockchain. To this
end, the precise value utilized in the header of the new block is
dependent on the hash value for each transaction in the new block,
as well as the hash value for each transaction in every prior
block.
[0034] According to certain aspects disclosed herein, information
stored in blockchains can be trusted, because the hash value
generated for the new block and a nonce value (an arbitrary number
used once) are used as inputs into a cryptographic puzzle. The
cryptographic puzzle may have a difficulty set by the nodes
connected to the blockchain network, or the difficulty may be set
by administrators of the blockchain network. In one example of the
cryptographic puzzle, a solving node uses the hash value generated
for the new block and repeatedly changes the value of the nonce
until a solution for the puzzle is found. For example, finding the
solution to the cryptographic puzzle may involve finding the nonce
value that meets certain criteria (e.g., the nonce value begins
with five zeros).
[0035] When a solution to the cryptographic puzzle is found, the
solving node publishes the solution and the other nodes then verify
that the solution is the correct solution. Because the solution
also depends on the particular hash values for each transaction
within the blockchain, if the solving node attempted to modify any
transaction, the solution would not be verified by the other nodes.
More particularly, if a single node attempts to modify a prior
transaction within the blockchain, a cascade of different hash
values are generated for each tier of the cryptographic combination
technique. This results in the header for one or more blocks being
different than the corresponding header(s) in every other node that
did not make the exact same modification.
[0036] As a result, the solution generated by the modifying node
would not solve the cryptographic puzzle presented to any node
without the identical modification. Thus, the version of the new
block generated by the modifying node is readily recognized as
including an improper modification and is rejected by the
consensus. This inability to modify past transactions lead to
blockchains being generally described as trusted, secure, and/or
immutable.
[0037] The systems and methods disclosed herein also include
performing actions utilizing the distributed consensus achieved
through the blockchain. In particular, these actions may be
executed by smart contracts. A smart contract is a computer
protocol that enables the automatic execution and/or enforcement of
an agreement between different parties. The smart contract may
include one or more trigger conditions, that, when satisfied,
correspond to one or more actions. For some smart contracts, which
action(s) from the one or more actions are performed is determined
based upon one or more decision conditions. Nodes on the network
may subscribe to one or more data streams including data related to
a trigger condition and/or a decision condition. Accordingly, the
nodes may route the data streams to the smart contract so that the
smart contract may detect that a trigger condition has occurred
and/or analyze a decision condition to direct the node to perform
one or more actions.
Exemplary Database & Distributed Ledger
[0038] FIG. 1A depicts an exemplary database system 100 in
accordance with one aspect of the present disclosure. FIG. 1A
includes a central authority 102, a plurality of nodes 104A, 104B,
and 106, a central ledger 108, and a plurality of network
connections 110. In one example operation of the database system
100, one of the nodes, for example Node A 104A, would issue a
request to the central authority 102 to perform an action on data
stored in the central ledger 108. This request may be a request to
create, read, update, or delete data that is stored in the central
ledger 108.
[0039] The central authority 102 would receive the request,
processes the request, make any necessary changes to the data
stored in the central ledger 108, and inform the requesting node,
Node A 104A, of the status of the request. The central authority
102 may also send out status updates to the other nodes on the
network about the change made, if any, to the data as requested by
Node A 104A. In the database system 100, all interaction with the
data stored in the central ledger 108 occurs through the central
authority 102. In this way, the central authority functions as a
gatekeeper of the data.
[0040] Accordingly, the central authority 102 operates a single
point of entry for interacting with the data, and consequently the
central authority 102 is a single point of failure for the entire
database system 100. As such, if the central authority 102 is not
accessible to the nodes in the database system 100, then the data
stored in the central ledger 108 is not accessible. In another
example, each individual node may keep their own databases and then
at the end of the day each node sends a copy of their database to
the central authority 102 where the databases received are
reconciled to form a single cohesive record of the data stored in
the central ledger 108.
[0041] Conversely, FIG. 1B depicts an exemplary distributed ledger
system 112 in accordance with one aspect of the present disclosure.
An example of a distributed ledger system 112 is the blockchain
system described above. FIG. 1B includes a plurality of nodes 104A,
104B, and 106, a distributed ledger 114, and network connections
110. In a distributed ledger system 112, each node keeps a copy of
the distributed ledger 114. As changes are made to the distributed
ledger 114 each node updates their copy of the distributed ledger
114. A consensus mechanism may be used by the nodes in the
distributed ledger system 112 to decide when it is appropriate to
make changes to the distributed ledger 114.
[0042] Therefore, each node has their own copy of the distributed
ledger 114, which is identical to every other copy of the
distributed ledger 114 stored by each other node. The distributed
ledger system 112 is more robust than a central authority database
system, which is depicted in FIG. 1A, because the distributed
ledger system 112 is decentralized and there is no single point of
failure.
Exemplary Transaction Flow & Block Propagation
[0043] FIG. 2A depicts an exemplary transaction flow 200 in
accordance with one aspect of the present disclosure. FIG. 2A
includes a transaction 202, three different time frames 204, 206,
and 208, a set of nodes, network connections 110, and a distributed
ledger 114. The transaction flow 200 may represent a sequential
flow of a transaction through a network, such as the network
depicted in FIG. 1B. For example, at time 204 Node A 104A generates
a transaction 202.
[0044] The transaction 202 may use data that is stored in the
distributed ledger 114, or the transaction 202 may use data
received by the node from outside the distributed ledger 114. Node
A 104A may transmit the newly generated transaction to Node C 106
via the network connection 110. At time 206, Node C 106 receives
the transaction 202 and confirms that the information contained
therein is correct. If the information contained in the transaction
202 is not correct Node C 106 may reject the transaction and not
propagate the transaction 202 through the system. If the
information contained in the transaction 202 is correct Node C 106
may transmit the transaction 202 to its neighbor Node B 104B.
[0045] Similarly, at time 208 Node B 104B may receive the
transaction 202 and either confirm or reject the transaction 202.
In some embodiments, the Node B 104B may not transmit the confirmed
transaction 202, because there are no further nodes to transmit to,
or all the nodes in the network have already received transaction
202.
[0046] In some embodiments, at any of time frames 204, 206, or 208,
any of the nodes may add the confirmed transaction 202 to their
copy of the distributed ledger 114, or to a block of transactions
stored in the distributed ledger. In some embodiments, confirming
the transaction 202 includes checking a cryptographic key-pair for
participants involved in the transaction 202. Checking the
cryptographic key-pair may follow a set method laid out by a
consensus protocol, such as the consensus protocol discussed in
FIG. 1B.
[0047] FIG. 2B depicts an exemplary block propagation 210 in
accordance with one aspect of the present disclosure. FIG. 2B
includes two time frames 212 and 214, Node C 106 and Node B 104B, a
set of transactions 202A-202D, a set of blocks of transactions
216A-216D, a distributed ledger 114, and a blockchain 218. The
block propagation 210 may follow the blockchain system described
above, or may follow another blockchain propagation algorithm.
[0048] The block propagation 210 may begin with Node C 106
receiving transaction 202A at time 212. When Node C 106C confirms
that transaction 202A is valid, the node may add the transaction to
a newly generated block 216. As part of adding the transaction 202A
to block 216, Node C 106 may solve a cryptographic puzzle and
include the solution in the newly generated block 216 as proof of
the work done to generate the block 216. This proof of work may be
similar to the proof of work described above which utilizes
guessing a nonce value. In other embodiments, the transaction 202A
may be added to a pool of transactions until enough transactions
exist to add together to create a block. Node C 106 may transmit
the newly created block 216 to the network at 220. Before or after
propagating the block 216, Node C 106 may add the block 216 to its
copy of the blockchain 218.
[0049] At time 214 Node B 104B may receive the newly created block
216. Node B 104B may verify that the block of transactions 216 is
valid by checking the solution to the cryptographic puzzle provided
in the block 216. If the solution is accurate then Node B 104B may
add the block 216 to its blockchain 218 and transmit the block 216
to the rest of the network at 222.
Exemplary Sequence Diagram
[0050] FIG. 3 depicts an exemplary sequence diagram 300 in
accordance with one aspect of the present disclosure. FIG. 3
includes a set of nodes 104A, 104B, and 106. At 302, Node A 104A
may generate a transaction. The transaction may be transmitted from
Node A 104A to Node C 106 at 304. Node C 106 may validate the
transaction at 306, and if the transaction is valid, transmit the
transaction at 308 to Node B 104B. Node B 104B may validate the
transaction at 310. At 312, Node C 106 may compile a block at 312
including the validated transaction. Compiling a block may include
generating a solution to a cryptographic puzzle, and linking the
block to other blocks, as described in the embodiments above. Once
the block is compiled, Node C 106 may transmit the block with the
solution at 314 to both Node A 104A and Node B 104B.
[0051] Both nodes may then validate the solution to the block at
316. Verifying may include checking a cryptographic key-pair as
described above. At 318 the three nodes form a consensus that the
solution is valid, and accordingly all the nodes have formed a
consensus on the blocks of transactions stored by all the
nodes.
Exemplary Node
[0052] FIG. 4 depicts an exemplary node 400 in accordance with one
aspect of the present disclosure. In some embodiments, node 400 may
be the same type of node as Node C 106 in FIGS. 1A-3. In other
embodiments, node 400 may be the same type of node as Node A 104A
and Node B 104B in FIGS. 1A-3. Node 400 may be capable of
performing all the embodiments disclosed herein. In particular,
node 400 may utilize the decentralized system described in FIG. 1B,
the flows of transactions and blocks described in FIGS. 2A and 2B,
and the blockchain system 500 described below in FIG. 5.
[0053] FIG. 4 includes at least one processor 402, memory 404, a
communication module 406, a set of applications 408, external ports
410, user interface 412, a blockchain manager 414, smart contracts
416, operating system 418, a display screen 420, and input/output
components 422. In some embodiments, the node 400 may generate a
new block of transactions by using the blockchain manager 414.
Similarly, the node 400 may use the blockchain manager 414 in
conjunction with the smart contracts 416 stored in memory 404 to
execute the functionality disclosed herein.
[0054] In other embodiments, the smart contracts 416 operate
independent of the blockchain manager 414 or other applications. In
some embodiments, node 400 does not have a blockchain manager 414,
or smart contracts 416 stored at the node. In some embodiments, the
node 400 may have additional or less components than what is
described. The components of the node 400 are described in more
detail below.
[0055] The node 400, as part of a decentralized ledger system 112,
or another decentralized or centralized network, may be used to
handle systems that interact with and manipulate data and
transactions designed for banking identity authentication, banking
account funding and distribution, banking card activation, actions
triggered by a death registry, using and accessing asset data, lien
perfection, obtaining settlement values, contractor ratings, single
view of customer's products, and associate licensing.
Exemplary Blockchain System
[0056] FIG. 5 depicts an exemplary blockchain system 500 in
accordance with one aspect of the present disclosure. FIG. 5
includes a blockchain 502, a block of transactions 504, a Merkle
Tree 506, and a transaction 508. The Merkle Tree may be the same
Merkle Tree described above that cryptographically links
transactions together. In other embodiments, the blockchain system
500 may utilize a different method of organizing transactions in a
block. In some embodiments, the blockchain system 500 includes a
plurality of blocks connected together to form a chain of blocks of
transactions 502.
[0057] Each block of transactions 504 may include at least one
transaction 508. In other embodiments, each block of transactions
504 has a size limit that necessarily limits the number of
transactions that the block may store. Each block of transactions
504 includes a reference to a previous block of transactions that
was added to the blockchain 502 prior to the block of transactions
504 being added to the blockchain 502. As such, and as described
above, each block of transactions 504 is linked to every other
block in the blockchain 502.
[0058] In some embodiments, the block of transactions 504 may
organize the transactions it has received into a Merkle Tree 506 to
facilitate access to the stored transactions. The transactions may
be hashed using a cryptographic hash algorithm, such as the
algorithms discussed above, and the hash of each transaction is
stored in the tree. As the tree is constructed the hash of each
adjacent node is hashed together to create a new node that exists
at a higher level in the tree. Therefore, the root of the tree, or
the node at the top of the tree, is dependent upon the hash of each
transaction stored in the tree. Each transaction 508 may include a
set of data 510. The set of data 510 may include identifying data
for the transaction, and transaction data identifying the nature of
the transaction and what the transactions entails.
Exemplary Banking Identity Authentication
[0059] FIG. 6 depicts an exemplary flow diagram 600 for a
computer-implemented method for manipulating and accessing a
blockchain containing identity authentication information for
banking services maintained by a network of participants. In some
embodiments, the network of participants may be the nodes described
above, for example node 400 depicted in FIG. 4. The blockchain used
by the participants may be the blockchain 500 depicted in FIG. 5,
whose operation is described in FIGS. 2A, 2B, and 5. The steps of
the method 600 may be performed by the nodes in the network of
participants, such as the nodes described in FIGS. 1A-4. The method
600 may include additional, fewer, or alternative actions,
including those described elsewhere herein.
[0060] The exemplary flow diagram 600 includes receiving at least
one bank transaction from at least one participant (block 602).
Verifying the at least one bank transaction (block 604). When the
transaction is not valid, generating and communicating a
confirmation that the bank transaction is not valid (block 606), or
alternatively, when the transaction is valid, adding the bank
transaction to a block of transactions (block 608). Generating a
cryptographic hash for the block of bank transactions (block 610).
Solving a cryptographic puzzle involving the generated hash (block
612), adding the block to the blockchain (block 614), and
transmitting the block to at least one other participant.
Exemplary Banking Account Funding and Distribution
[0061] FIG. 7 depicts an exemplary flow diagram 700 for a
computer-implemented method for account funding and distribution
using smart contracts stored on a blockchain maintained by a
plurality of participants. In some embodiments, the network of
participants may be the nodes described above, for example node 400
depicted in FIG. 4. The blockchain used by the participants may be
the blockchain 500 depicted in FIG. 5, whose operation is described
in FIGS. 2A, 2B, and 5. The steps of the computer-implemented
method 700 may be performed by the nodes in the network of
participants, such as the nodes described in FIGS. 1A-4. The method
700 may include additional, fewer, or alternative actions,
including those described elsewhere herein.
[0062] The systems and methods described herein may help an
individual and a business manage the account funding and
distribution process using smart contracts stored on a blockchain
maintained by a plurality of participants. For example, a business
(e.g., a bank) may have a smart contract stored on a blockchain
that automates the process of adding/subtracting/distributing funds
to/from an account. That smart contract may be stored at a
particular address in the blockchain that allows participants in
the blockchain network to send funds and other data in a
transaction to that address. The smart contract may have particular
conditions that must be met for particular actions to take place.
Assuming that the conditions in the smart contract are met, when a
transaction is sent to the address where the smart contract is
stored, the particular actions are executed.
[0063] The particular actions may be, for example, a customer of a
bank wishing to send money to their checking with the bank. The
customer may send a transaction with an amount of money, as well as
their account information and any validating information for the
account, to the address where the smart contract is stored. Once
the information in the transaction is confirmed by the participants
in the blockchain network as adhering to the conditions dictated in
the smart contract the funds may be added/subtracted/disbursed
to/from the customer's account. Other actions may be performed
using the smart contracts stored in the blockchain network, such as
for example: transferring accounts, linking accounts to each other,
allowing reporting or monitoring of accounts, and deleting
accounts.
[0064] The exemplary flow diagram 700 may include, via one or more
processors, servers, and/or transceivers, (1) receiving (such as
via wireless communication or data transmission over one or more
radio frequency links or communication channels) at least one
transaction from at least one participant, wherein the at least one
transaction has a set of parameters (block 702); (2) verifying the
at least one transaction, wherein verifying includes accessing a
smart contract stored on the blockchain and checking the set of
parameters against a set of conditions stored in the smart contract
(block 704); and, (3) when the set of parameters satisfy the set of
conditions, indicating a change in a fund balance for the at least
one participant (block 706), and (4) generating and transmitting
(such as via wireless communication or data transmission over one
or more radio frequency links or communication channels) a
confirmation to the at least one participant that the transaction
has been approved (block 708). And, (5) alternatively, when the set
of parameters do not satisfy the set of conditions, the flow may
include, via one or more processors, servers, and/or transceivers,
generating and transmitting (such as via wireless communication or
data transmission over one or more radio frequency links or
communication channels) a rejection to the at least one participant
that the transaction has been rejected (block 710).
[0065] In some embodiments, the at least one transaction is a new
account funding transaction. As part of the new account funding
transaction a participant in the blockchain network may include
funds in the transaction as well as other information necessary for
the transaction. The funds may be added to the transaction by the
participant that initiated the transaction, or may be added to the
transaction by another participant on the blockchain network. In
some embodiments, the set of parameters contained in the
transaction include personally identifiable information for at
least one person and an amount of funds. Examples of personally
identifiable information may include a person's full name, a
person's address information, a person's age, or other identifying
information about the person.
[0066] In some embodiments, the set of conditions may be a list of
requirements for funding an account stored on the blockchain
corresponding to the transaction, and verifying that the at least
one participant has ownership of an amount of funds being used to
fund the account. The requirements may include particular
information required by a financial institution to comply with
regulations, such as, know your customer regulations and anti-money
laundering regulations. Accordingly, when there is no account
stored on the blockchain corresponding to the transaction, the
method may include creating a new account on the blockchain for the
at least one participant using the funds included in the
transaction.
[0067] In some embodiments, indicating a change in a fund balance
for the at least one participant, may include adding funds included
in the transaction to an account controlled by the at least one
participant. In other embodiments, the method may further include
receiving (such as via wireless communication or data transmission
over one or more radio frequency links or communication channels) a
block of transactions; verifying the block of transactions;
transmitting (such as via wireless communication or data
transmission over one or more radio frequency links or
communication channels) the block of transactions to at least one
other participant; and/or adding the block of transactions to a
copy of the blockchain. Verifying the block may include solving a
cryptographic puzzle, and including the solution to the
cryptographic puzzle in the block of transactions.
[0068] In some embodiments of the method for account funding and
distribution using smart contracts stored on a blockchain
maintained by a plurality of participants, the method may include
receiving (such as via wireless communication or data transmission
over one or more radio frequency links or communication channels) a
request for funds from at least one participant, wherein the
request for funds has a set of parameters; verifying the request
for funds, wherein verifying may include accessing a smart contract
stored on the blockchain and checking the set of parameters against
a set of conditions stored in the smart contract; and when the set
of parameters satisfy the set of conditions, satisfying the request
for funds by transmitting (such as via wireless communication or
data transmission over one or more radio frequency links or
communication channels) the corresponding amount of funds to the at
least one participant; generating and transmitting (such as via
wireless communication or data transmission over one or more radio
frequency links or communication channels) a confirmation to the at
least one participant that the request for funds has been approved;
generating a block of transactions representative of requests for
funds containing the at least one request for funds, and
transmitting (such as via wireless communication or data
transmission over one or more radio frequency links or
communication channels) the block of transactions to at least one
participant; and, alternatively, when the set of parameters do not
satisfy the set of conditions, generating and transmitting (such as
via wireless communication or data transmission over one or more
radio frequency links or communication channels) a rejection to the
at least one participant that the request for funds has been
rejected. The methods may include additional, less, or alternate
actions, including that discussed elsewhere herein.
Exemplary Banking Card Activation
[0069] FIG. 8 depicts an exemplary flow diagram 800 for a
computer-implemented method for credit card activation using a
smart contract stored on a blockchain maintained by a plurality of
participants. In some embodiments, the network of participants may
be the nodes described above, for example node 400 depicted in FIG.
4. The blockchain used by the participants may be the blockchain
500 depicted in FIG. 5, whose operation is described in FIGS. 2A,
2B, and 5. The steps of the method 800 may be performed by the
nodes in the network of participants, such as the nodes described
in FIGS. 1A-4. The method 800 may include additional, fewer, or
alternative actions, including those described elsewhere
herein.
[0070] The exemplary flow diagram 800 includes receiving, at a
processor, at least one credit card application package associated
with a credit card, wherein the credit card application package
includes credit card information and a set of user information
(block 802). Verifying, at the processor, the credit card
information and the set of user information (block 804). Checking,
at the processor, the credit card information and the set of user
information against the smart contract stored on the blockchain,
wherein the smart contract includes a set of conditions (block
806). Activating, at the processor, the credit card when the credit
card information and the set of user information satisfy the set of
conditions stored in the smart contract (block 808).
Exemplary Actions Triggered by a Passing Registry
[0071] FIG. 9 depicts an exemplary flow diagram 900 for a
computer-implemented method for performing actions designated in
smart contracts, stored on a blockchain maintained by a plurality
of participants, based upon notification of a person's death or
passing. In some embodiments, the network of participants may be
the nodes described above, for example node 400 depicted in FIG. 4.
The blockchain used by the participants may be the blockchain 500
depicted in FIG. 5, whose operation is described in FIGS. 2A, 2B,
and 5. The steps of the method 900 may be performed by the nodes in
the network of participants, such as the nodes described in FIGS.
1A-4. The method 900 may include additional, fewer, or alternative
actions, including those described elsewhere herein.
[0072] The exemplary flow diagram 900 includes receiving, at a
processor coupled with a network interface, at least one passing or
death registry notification, wherein the passing or death registry
notification has a set of personal information (block 902).
Verifying, at the processor, the passing or death registry
notification and the set of personal information (block 904).
Accessing, at the processor, a set of documents relevant to the set
of personal information (block 906). Generating, at the processor,
a passing or death registry action based upon the set of documents,
the set of personal information, and the passing or death registry
notification (block 908). Checking, at the processor, the passing
or death registry action against a smart contract stored on the
blockchain, wherein the set of documents has a set of conditions
(block 910). Executing, at the processor, the passing or death
registry action when the passing or death registry action satisfies
the set of conditions (block 912).
Exemplary Using and Accessing Asset Data
[0073] FIG. 10 depicts an exemplary flow diagram 1000 for a
computer-implemented method for using and accessing asset data
stored on a blockchain maintained by a plurality of participants.
In some embodiments, the network of participants may be the nodes
described above, for example node 400 depicted in FIG. 4. The
blockchain used by the participants may be the blockchain 500
depicted in FIG. 5, whose operation is described in FIGS. 2A, 2B,
and 5. The steps of the method 1000 may be performed by the nodes
in the network of participants, such as the nodes described in
FIGS. 1A-4. The method 1000 may include additional, fewer, or
alternative actions, including those described elsewhere
herein.
[0074] The exemplary flow diagram 1000 may include receiving, at a
processor coupled to a network interface, at least one request from
at least one user for asset data stored on the blockchain, wherein
the request includes a set of request parameters (block 1002).
Analyzing, at the processor, the at least one request to determine
a type of request (block 1004). Accessing, at the processor, the
asset data stored on the blockchain based upon the type of request
and the set of request parameters (block 1006). Performing, at the
processor, an action involving the asset data based upon the
request (block 1008). Communicating, via the processor coupled to
the network interface, to the at least one user that the action was
performed involving the asset data (block 1010).
Exemplary Lien Perfection
[0075] FIG. 11 depicts an exemplary flow diagram 1100 for a
computer-implemented method for lien perfection using smart
contracts stored on a blockchain maintained by a plurality of
participants. In some embodiments, the network of participants may
be the nodes described above, for example node 400 depicted in FIG.
4. The blockchain used by the participants may be the blockchain
500 depicted in FIG. 5, whose operation is described in FIGS. 2A,
2B, and 5. The steps of the method 1100 may be performed by the
nodes in the network of participants, such as the nodes described
in FIGS. 1A-4. The method 1100 may include additional, fewer, or
alternative actions, including those described elsewhere
herein.
[0076] The exemplary flow diagram 1100 includes receiving, at a
processor coupled with a network interface, at least one security
interest notification, wherein the security interest notification
has a set of lienholder information for an asset (block 1102).
Verifying, at the processor, the security interest notification and
the set of lienholder information (block 1104). Accessing, at the
processor, a smart contract stored on the blockchain, wherein the
smart contract has a set of conditions which indicate at least a
priority process (block 1106). Executing, at the processor, the
priority process when the set of conditions are satisfied by the
security interest notification and the set of lienholder
information (block 1108). Generating, at the processor, a
transaction containing the security interest (block 1110).
Communicating, via the processor coupled with the network
interface, the transaction to the network of participants (block
1112).
Exemplary Obtaining Settlement Values
[0077] FIG. 12 depicts an exemplary flow diagram 1200 for a
computer-implemented method for obtaining settlement values for a
set of lienholders with a security interest in an asset stored on a
blockchain maintained by a plurality of participants using smart
contracts. In some embodiments, the network of participants may be
the nodes described above, for example node 400 depicted in FIG. 4.
The blockchain used by the participants may be the blockchain 500
depicted in FIG. 5, whose operation is described in FIGS. 2A, 2B,
and 5. The steps of the method 1200 may be performed by the nodes
in the network of participants, such as the nodes described in
FIGS. 1A-4. The method 1200 may include additional, fewer, or
alternative actions, including those described elsewhere
herein.
[0078] The exemplary flow diagram 1200 includes receiving, at a
processor coupled with a network interface, at least one
foreclosure notification for at least one asset stored on a
blockchain, wherein the at least one foreclosure notification
includes at least one request for a set of settlement values from
one of the plurality of participants (block 1202). Verifying, at
the processor, the at least one foreclosure notification (block
1204). Accessing, at the processor, the at least one asset stored
on the blockchain, wherein the asset has a set of lienholder
information and a smart contract priority process, wherein the
smart contract priority process indicates the settlement values for
each member of the set of lienholders (block 1206). Executing, at
the processor, the smart contract priority process to recalculate
and distribute the settlement values for each member of the set of
lienholders (block 1208). Communicating and distributing, via the
processor coupled with the network interface, the recalculated
settlement values to the at least one plurality of participants
that requested the set of settlement values (block 1210).
Exemplary Contractor Ratings
[0079] FIG. 13 depicts an exemplary flow diagram 1300 for a
computer-implemented method for using and accessing contractor
evaluations stored on a blockchain maintained by a plurality of
participants In some embodiments, the network of participants may
be the nodes described above, for example node 400 depicted in FIG.
4. The blockchain used by the participants may be the blockchain
500 depicted in FIG. 5, whose operation is described in FIGS. 2A,
2B, and 5. The steps of the method 1300 may be performed by the
nodes in the network of participants, such as the nodes described
in FIGS. 1A-4. The method 1300 may include additional, fewer, or
alternative actions, including those described elsewhere
herein.
[0080] The exemplary flow diagram 1300 includes receiving, at a
processor coupled to a network interface, at least one contractor
evaluation for a contractor from at least one participant of the
plurality of participants, wherein the at least one contractor
evaluation includes an evaluation, an evaluationer, and a set of
contractor information (block 1302). Verifying, at the processor,
the evaluation, the evaluationer, and the set of contractor
information (block 1304). Verifying, at the processor, that the set
of contractor information is stored on the blockchain (block 1306).
When the set of contractor information is stored on the blockchain,
generating, at the processor, a transaction involving the set of
contractor information and the evaluation (block 1308), and when
the set of contractor information is not stored on the blockchain,
generating, at the processor, a transaction involving the set of
contractor information and the evaluation (block 1310).
Transmitting, via the processor coupled to the network interface,
the transaction to the plurality of participants (block 1312).
Exemplary Single View of Customer's Products
[0081] FIG. 14 depicts an exemplary flow diagram 1400 for a
computer-implemented method for using and accessing customer
information stored on a blockchain maintained by a plurality of
participants. In some embodiments, the network of participants may
be the nodes described above, for example node 400 depicted in FIG.
4. The blockchain used by the participants may be the blockchain
500 depicted in FIG. 5, whose operation is described in FIGS. 2A,
2B, and 5. The steps of the method 1400 may be performed by the
nodes in the network of participants, such as the nodes described
in FIGS. 1A-4. The method 1400 may include additional, fewer, or
alternative actions, including those described elsewhere
herein.
[0082] The exemplary flow diagram 1400 includes receiving, at a
processor coupled to a network interface, at least one customer
request for customer information stored on the blockchain from at
least one participant of the plurality of participants (block
1402). Verifying, at the processor, the customer information
request (block 1404). Verifying, at the processor, that the
customer information is stored on the blockchain (block 1406), and
when the customer information is stored on the blockchain
generating, at the processor, a customer information action and
transaction (block 1408), and when the customer information is not
stored on the blockchain, generating, at the processor, a
transaction involving the customer information request (block
1410). Transmitting, via the processor coupled to the network
interface, the transaction to the plurality of participants (block
1412).
Exemplary Associate Information and Licensing
[0083] FIG. 15 depicts an exemplary flow diagram 1500 for a
computer-implemented method for using and accessing associate data
stored on a blockchain maintained by a plurality of participants In
some embodiments, the network of participants may be the nodes
described above, for example node 400 depicted in FIG. 4. The
blockchain used by the participants may be the blockchain 500
depicted in FIG. 5, whose operation is described in FIGS. 2A, 2B,
and 5. The steps of the method 1500 may be performed by the nodes
in the network of participants, such as the nodes described in
FIGS. 1A-4. The method 1500 may include additional, fewer, or
alternative actions, including those described elsewhere
herein.
[0084] The exemplary flow diagram 1500 includes receiving, at a
processor coupled to a network interface, at least one associate
request, the associate request having an associate request type,
from at least one participant of the plurality of participants for
information on an associate stored on the blockchain, wherein the
at least one associate request includes associate identifying
information, associate sales data, and associate licensing data
(block 1502). Verifying, at the processor, the associate request
based upon the associate request type (block 1504). Verifying, at
the processor, that the associate information is stored on the
blockchain (block 1506). When the associate information is stored
on the blockchain, generating, at the processor, a transaction
corresponding to the associate request type (block 1508), and when
the associate information is not stored on the blockchain,
generating, at the processor, a transaction involving the associate
identifying information, associate sales data, and associate
licensing data (block 1510). Transmitting, via the processor
coupled to the network interface, the transaction to the plurality
of participants (block 1512).
Additional Considerations
[0085] This detailed description is to be construed as exemplary
only and does not describe every possible embodiment, as describing
every possible embodiment would be impractical, if not impossible.
One may be implement numerous alternate embodiments, using either
current technology or technology developed after the filing date of
this application.
[0086] Further to this point, although the embodiments described
herein often utilize credit report information as an example of
sensitive information, the embodiments described herein are not
limited to such examples. Instead, the embodiments described herein
may be implemented in any suitable environment in which it is
desirable to identify and control specific type of information. For
example, the aforementioned embodiments may be implemented by a
financial institution to identify and contain bank account
statements, brokerage account statements, tax documents, etc. To
provide another example, the aforementioned embodiments may be
implemented by a lender to not only identify, re-route, and
quarantine credit report information, but to apply similar
techniques to prevent the dissemination of loan application
documents that are preferably delivered to a client for signature
in accordance with a more secure means (e.g., via a secure login to
a web server) than via email.
[0087] Furthermore, although the present disclosure sets forth a
detailed description of numerous different embodiments, it should
be understood that the legal scope of the description is defined by
the words of the claims set forth at the end of this patent and
equivalents. The detailed description is to be construed as
exemplary only and does not describe every possible embodiment
since describing every possible embodiment would be impractical.
Numerous alternative embodiments may be implemented, using either
current technology or technology developed after the filing date of
this patent, which would still fall within the scope of the claims.
Although the following text sets forth a detailed description of
numerous different embodiments, it should be understood that the
legal scope of the description is defined by the words of the
claims set forth at the end of this patent and equivalents. The
detailed description is to be construed as exemplary only and does
not describe every possible embodiment since describing every
possible embodiment would be impractical. Numerous alternative
embodiments may be implemented, using either current technology or
technology developed after the filing date of this patent, which
would still fall within the scope of the claims.
[0088] The following additional considerations apply to the
foregoing discussion. Throughout this specification, plural
instances may implement components, operations, or structures
described as a single instance. Although individual operations of
one or more methods are illustrated and described as separate
operations, one or more of the individual operations may be
performed concurrently, and nothing requires that the operations be
performed in the order illustrated. Structures and functionality
presented as separate components in example configurations may be
implemented as a combined structure or component. Similarly,
structures and functionality presented as a single component may be
implemented as separate components. These and other variations,
modifications, additions, and improvements fall within the scope of
the subject matter herein.
[0089] Additionally, certain embodiments are described herein as
including logic or a number of routines, subroutines, applications,
or instructions. These may constitute either software (e.g., code
embodied on a machine-readable medium or in a transmission signal)
or hardware. In hardware, the routines, etc., are tangible units
capable of performing certain operations and may be configured or
arranged in a certain manner. In exemplary embodiments, one or more
computer systems (e.g., a standalone, client or server computer
system) or one or more hardware modules of a computer system (e.g.,
a processor or a group of processors) may be configured by software
(e.g., an application or application portion) as a hardware module
that operates to perform certain operations as described
herein.
[0090] In various embodiments, a hardware module may be implemented
mechanically or electronically. For example, a hardware module may
comprise dedicated circuitry or logic that is permanently
configured (e.g., as a special-purpose processor, such as a field
programmable gate array (FPGA) or an application-specific
integrated circuit (ASIC)) to perform certain operations. A
hardware module may also comprise programmable logic or circuitry
(e.g., as encompassed within a general-purpose processor or other
programmable processor) that is temporarily configured by software
to perform certain operations. It will be appreciated that the
decision to implement a hardware module mechanically, in dedicated
and permanently configured circuitry, or in temporarily configured
circuitry (e.g., configured by software) may be driven by cost and
time considerations.
[0091] Accordingly, the term "hardware module" should be understood
to encompass a tangible entity, be that an entity that is
physically constructed, permanently configured (e.g., hardwired),
or temporarily configured (e.g., programmed) to operate in a
certain manner or to perform certain operations described herein.
Considering embodiments in which hardware modules are temporarily
configured (e.g., programmed), each of the hardware modules need
not be configured or instantiated at any one instance in time. For
example, where the hardware modules comprise a general-purpose
processor configured using software, the general-purpose processor
may be configured as respective different hardware modules at
different times. Software may accordingly configure a processor,
for example, to constitute a particular hardware module at one
instance of time and to constitute a different hardware module at a
different instance of time.
[0092] Hardware modules may provide information to, and receive
information from, other hardware modules. Accordingly, the
described hardware modules may be regarded as being communicatively
coupled. Where multiple of such hardware modules exist
contemporaneously, communications may be achieved through signal
transmission (e.g., over appropriate circuits and buses) that
connect the hardware modules. In embodiments in which multiple
hardware modules are configured or instantiated at different times,
communications between such hardware modules may be achieved, for
example, through the storage and retrieval of information in memory
structures to which the multiple hardware modules have access. For
example, one hardware module may perform an operation and store the
output of that operation in a memory device to which it is
communicatively coupled. A further hardware module may then, at a
later time, access the memory device to retrieve and process the
stored output. Hardware modules may also initiate communications
with input or output devices, and may operate on a resource (e.g.,
a collection of information).
[0093] The various operations of example methods described herein
may be performed, at least partially, by one or more processors
that are temporarily configured (e.g., by software) or permanently
configured to perform the relevant operations. Whether temporarily
or permanently configured, such processors may constitute
processor-implemented modules that operate to perform one or more
operations or functions. The modules referred to herein may, in
some example embodiments, comprise processor-implemented
modules.
[0094] Similarly, the methods or routines described herein may be
at least partially processor-implemented. For example, at least
some of the operations of a method may be performed by one or more
processors or processor-implemented hardware modules. The
performance of certain of the operations may be distributed among
the one or more processors, not only residing within a single
machine, but deployed across a number of machines. In some example
embodiments, the processor or processors may be located in a single
location (e.g., within a home environment, an office environment or
as a server farm), while in other embodiments the processors may be
distributed across a number of locations.
[0095] The performance of certain of the operations may be
distributed among the one or more processors, not only residing
within a single machine, but deployed across a number of machines.
In some example embodiments, the one or more processors or
processor-implemented modules may be located in a single geographic
location (e.g., within a home environment, an office environment,
or a server farm). In other example embodiments, the one or more
processors or processor-implemented modules may be distributed
across a number of geographic locations.
[0096] Unless specifically stated otherwise, discussions herein
using words such as "processing," "computing," "calculating,"
"determining," "presenting," "displaying," or the like may refer to
actions or processes of a machine (e.g., a computer) that
manipulates or transforms data represented as physical (e.g.,
electronic, magnetic, or optical) quantities within one or more
memories (e.g., volatile memory, non-volatile memory, or a
combination thereof), registers, or other machine components that
receive, store, transmit, or display information.
[0097] As used herein any reference to "one embodiment" or "an
embodiment" means that a particular element, feature, structure, or
characteristic described in connection with the embodiment is
included in at least one embodiment. The appearances of the phrase
"in one embodiment" in various places in the specification are not
necessarily all referring to the same embodiment.
[0098] Some embodiments may be described using the expression
"coupled" and "connected" along with their derivatives. For
example, some embodiments may be described using the term "coupled"
to indicate that two or more elements are in direct physical or
electrical contact. The term "coupled," however, may also mean that
two or more elements are not in direct contact with each other, but
yet still co-operate or interact with each other. The embodiments
are not limited in this context.
[0099] As used herein, the terms "comprises," "comprising,"
"includes," "including," "has," "having" or any other variation
thereof, are intended to cover a non-exclusive inclusion. For
example, a process, method, article, or apparatus that comprises a
list of elements is not necessarily limited to only those elements
but may include other elements not expressly listed or inherent to
such process, method, article, or apparatus. Further, unless
expressly stated to the contrary, "or" refers to an inclusive or
and not to an exclusive or. For example, a condition A or B is
satisfied by any one of the following: A is true (or present) and B
is false (or not present), A is false (or not present) and B is
true (or present), and both A and B are true (or present).
[0100] In addition, use of the "a" or "an" are employed to describe
elements and components of the embodiments herein. This is done
merely for convenience and to give a general sense of the
description. This description, and the claims that follow, should
be read to include one or at least one and the singular also
includes the plural unless it is obvious that it is meant
otherwise.
[0101] The patent claims at the end of this patent application are
not intended to be construed under 35 U.S.C. .sctn. 112(f) unless
traditional means-plus-function language is expressly recited, such
as "means for" or "step for" language being explicitly recited in
the claim(s).
* * * * *