U.S. patent application number 15/870332 was filed with the patent office on 2021-09-09 for distributed ledger system for insurance record management systems.
The applicant listed for this patent is STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY. Invention is credited to Jacob J. Alt, Eric Bellas, Ronny S. Bryant, Shawn M. Call, Mitchell J. Hill, Vicki King, Melinda Teresa Magerkurth, Stacie A. McCullough, Jaime Skaggs.
Application Number | 20210279808 15/870332 |
Document ID | / |
Family ID | 1000003161172 |
Filed Date | 2021-09-09 |
United States Patent
Application |
20210279808 |
Kind Code |
A1 |
Bryant; Ronny S. ; et
al. |
September 9, 2021 |
DISTRIBUTED LEDGER SYSTEM FOR INSURANCE RECORD MANAGEMENT
SYSTEMS
Abstract
Systems and methods are disclosed with respect to using a
distributed ledger, such as a blockchain, for insurance record
management systems. The distributed ledger may be utilized to look
up information pertaining to a person's insurance. For example,
when a driver is pulled over by law enforcement for speeding, the
driver may wish to verify an insurance policy by granting a law
enforcement official permission to view his or her insurance
records stored on the distributed ledger. Advantageously, the
distributed ledger could consequently eliminate the need to carry
physical proof of insurance.
Inventors: |
Bryant; Ronny S.;
(Bloomington, IL) ; McCullough; Stacie A.;
(Bloomington, IL) ; Hill; Mitchell J.;
(Bloomington, IL) ; Alt; Jacob J.; (Downs, IL)
; Skaggs; Jaime; (Chenoa, IL) ; Call; Shawn
M.; (Bloomington, IL) ; Bellas; Eric;
(Bloomington, IL) ; King; Vicki; (Bloomington,
IL) ; Magerkurth; Melinda Teresa; (Utica,
IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY |
Bloomington |
IL |
US |
|
|
Family ID: |
1000003161172 |
Appl. No.: |
15/870332 |
Filed: |
January 12, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62548668 |
Aug 22, 2017 |
|
|
|
62548679 |
Aug 22, 2017 |
|
|
|
62548682 |
Aug 22, 2017 |
|
|
|
62548692 |
Aug 22, 2017 |
|
|
|
62548741 |
Aug 22, 2017 |
|
|
|
62548700 |
Aug 22, 2017 |
|
|
|
62548731 |
Aug 22, 2017 |
|
|
|
62548748 |
Aug 22, 2017 |
|
|
|
62545262 |
Aug 14, 2017 |
|
|
|
62508133 |
May 18, 2017 |
|
|
|
62500049 |
May 2, 2017 |
|
|
|
62500326 |
May 2, 2017 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 40/08 20130101;
H04L 9/32 20130101; H04L 2209/38 20130101 |
International
Class: |
G06Q 40/08 20120101
G06Q040/08; H04L 9/32 20060101 H04L009/32 |
Claims
1. A computer-implemented method for managing insurance records for
policies for individuals, the method comprising: implementing a
plurality of servers, each of the plurality of servers maintaining
a copy of a distributed ledger; when an insurance policy is created
for a given individual, storing to the distributed ledger a
transaction record representing the created insurance policy,
including a policy number and a coverage amount for the created
insurance policy, wherein storing the transaction record includes:
(i) generating, at a first server from the plurality of servers,
the transaction record representing the created insurance policy;
(ii) proposing the transaction record to one or more other servers
from the plurality of servers; (iii) performing, via the plurality
of servers, a consensus analysis of the transaction record
utilizing a consensus mechanism; and (iv) when the consensus
analysis indicates that the plurality of servers have formed a
consensus, storing the transaction record at the distributed ledger
by storing the transaction record to each copy of the distributed
ledger at the plurality of servers; receiving, at the plurality of
servers, an electronic message including a request for a
verification regarding whether or not an individual of interest is
insured; responding, via the plurality of servers, to the request
for the verification by: (i) determining that the individual of
interest is the given individual and (ii) detecting that the
distributed ledger includes one or more transaction records
representing one or more insurance policies for the given
individual; and responding to detecting that the distributed ledger
includes one or more transaction records representing one or more
insurance policies for the given individual, including: (a)
generating the verification by retrieving from the distributed
ledger all of the one or more transaction records, including the
transaction record representing the created insurance policy, and
(b) generating a summary of all of the one or more insurance
policies represented by the retrieved one or more transaction
records, wherein the summary includes the policy number for the
created insurance policy.
2. The method of claim 1, wherein storing the transaction record at
the distributed ledger comprises: storing the transaction to a
block.
3. The method of claim 2, wherein performing the consensus analysis
comprises generating a hash value for the transaction, and
utilizing the hash value for the transaction to generate a hash
value for the block.
4. The method of claim 1, wherein the consensus mechanism is: a
proof of work mechanism, a proof of stake mechanism, or a proof of
activity mechanism.
5. The method of claim 1, wherein the consensus mechanism is: a
proof of burn mechanism, a proof of capacity mechanism, or a proof
of elapsed time mechanism.
6. The method of claim 1, wherein the transaction record includes
data representing: an identity of the given individual.
7. The method of claim 1, further including verifying that a
requestor that submitted the request for the verification is
authorized, wherein the verification is only generated when
requestor is authorized.
8. The method of claim 7, further comprising receiving from the
given individual a list of authorized parties; wherein verifying
that the requestor is authorized includes verifying that the
requestor is on the list of authorized parties.
9. The method of claim 7, further comprising receiving from an
insurance company a list of authorized parties; wherein verifying
that the requestor is authorized includes verifying that the
requestor is on the list of authorized parties.
10. (canceled)
11. A system for managing insurance records for a policies for
individuals, the system comprising: a plurality of servers
maintaining a distributed ledger for managing insurance records,
wherein each of the plurality of servers includes a memory storing:
(A) a copy of the distributed ledger, and (B) instructions that,
when executed, cause the respective server to: (i) generate, at the
respective server, a transaction record representing a created
insurance policy for given individual, including a policy number
and a coverage amount for the created insurance policy; wherein the
plurality of servers are configured to: (A) store to the
distributed ledger the transaction record representing the created
insurance policy, wherein the plurality of servers: (i) perform a
consensus analysis of the transaction record utilizing a consensus
mechanism; and (ii) store the transaction record at the distributed
ledger when the consensus analysis indicates that the plurality of
servers have formed a consensus by storing the transaction record
to each copy of the distributed ledger at the plurality of servers;
(B) receive an electronic message including a request for a
verification regarding whether or not an individual of interest is
insured; (C) respond to the request for the verification by: (i)
determining that the individual of interest is the given
individual, and (ii) detecting that the distributed ledger includes
one or more transaction records representing one or more insurance
policies for the given individual; and (D) respond to detecting
that the distributed ledger includes one or more transaction
records representing one or more insurance policies for the given
individual, including: (1) generate a verification of insurance
information for the individual of interest by retrieving from a
copy of the distributed ledger all of the one or more transaction
records, including the transaction record representing the created
insurance policy, and (2) generate a summary of all of the one or
more insurance policies represented by the retrieved one or more
transaction records, wherein the summary includes the policy number
for the created insurance policy.
12. The system of claim 11, wherein the plurality of servers are
configured to store the transaction record at the distributed
ledger by storing the transaction to a block.
13. The system of claim 12, wherein the plurality of servers are
configured to perform the consensus analysis by generating a hash
value for the transaction and utilizing the hash value for the
transaction to generate a hash value for the block.
14. The system of claim 11, wherein the consensus mechanism is: a
proof of work mechanism, a proof of stake mechanism, or a proof of
activity mechanism.
15. The system of claim 11, wherein the consensus mechanism is: a
proof of burn mechanism, a proof of capacity mechanism, or a proof
of elapsed time mechanism.
16. The system of claim 11, wherein the transaction record includes
data representing: an identity of the given individual.
17. The system of claim 11, wherein the plurality of servers are
further configured to verify that a requestor that submitted the
request for the verification is authorized, wherein the
verification is only generated when the requestor is
authorized.
18. The system of claim 17, wherein the plurality of servers are
further configured to receive from the given individual a list of
authorized parties; wherein the plurality of servers are configured
to verify that the requestor is authorized by verifying that the
requestor is on the list of authorized parties.
19. The system of claim 17, wherein the plurality of servers are
further configured to receive from an insurance company a list of
authorized parties; wherein the plurality of servers are further
configured to verify that the requestor is authorized by verifying
that the requestor is on the list of authorized parties.
20. (canceled)
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present disclosure claims the benefit of (i) U.S.
Provisional Patent Application No. 62/500,049, titled "Distributed
Ledger Systems," filed on May 2, 2017; (ii) U.S. Provisional Patent
Application No. 62/500,326, titled "Distributed Ledger System,"
filed on May 2, 2017; (iii) U.S. Provisional Patent Application No.
62/508,133, titled "Distributed Ledger System for Managing Smart
Home Data, Vehicle Data, Insurance Claim Payouts, and/or Insurance
Carrier Discovery," filed on May 18, 2017; (iv) U.S. Provisional
Patent Application No. 62,545,262, titled "Distributed Ledger
System for Managing Loss Histories," filed on Aug. 22, 2017; (v)
U.S. Provisional Patent Application No. 62,548,668, titled
"Distributed Ledger System for Managing Vehicle Sensor Data
Utilized to Develop Collision Profiles," filed on Aug. 22, 2017;
(vi) U.S. Provisional Patent Application No. 62,548,679, titled
"Distributed Ledger System for Use with Vehicle Sensor Data and
Usage Based Systems," filed on Aug. 22, 2017; (vii) U.S.
Provisional Patent Application No. 62,548,682, titled "Distributed
Ledger System for Managing Medical Records," filed on Aug. 22,
2017; (viii) U.S. Provisional Patent Application No. 62,548,692,
titled "Distributed Ledger System for Insurance Record Management
Systems," filed on Aug. 22, 2017; (ix) U.S. Provisional Patent
Application No. 62,548,741, titled "Distributed Ledger System for
Smart Home Data," filed on Aug. 22, 2017; (x) U.S. Provisional
Patent Application No. 62,548,700, titled "Distributed Ledger
System for Managing Smart Vehicle Data," filed on Aug. 22, 2017;
(xi) U.S. Provisional Patent Application No. 62,548,731, titled
"Distributed Ledger System for Claim Payouts," filed on Aug. 22,
2017; and (xii) U.S. Provisional Patent Application No. 62,548,748,
titled "Distributed Ledger System for Carrier Discovery," filed on
Aug. 22, 2017; the entire disclosures of which are expressly
incorporated herein by reference.
TECHNICAL FIELD
[0002] Systems and methods are disclosed with respect to using a
distributed ledger for insurance record management systems.
BACKGROUND
[0003] Generally speaking, insurance companies may utilize
centralized databases or servers for a number of purposes. For
example, insurance records are generally held by individual
insurance companies at a centralized database and are not readily
available to third parties who wish, for example, to verify that a
person is currently insured.
BRIEF SUMMARY
[0004] The present embodiments may detail an individual's insurance
information. For instance, a blockchain associated with an
individual may include or link to their past or current insurance
policies. As an example, the blockchain may include data or a block
that acts as a proof of auto or homeowners insurance.
[0005] In one aspect, a computer-implemented method for managing
insurance records may include (1) configuring or implementing a
plurality of servers, each of the plurality of servers maintaining
a copy of a distributed ledger; (2) creating, at the distributed
ledger, a record of an insurance policy when the insurance policy
is created for an individual; and/or (3) when a request for a
verification of insurance information is received, generating the
verification by retrieving from the distributed ledger all
transaction records pertaining to the individual, and generating a
summary of all insurance policies represented by the retrieved
transaction records. Creating the record of the insurance policy at
the distributed ledger may include performing one or more of the
following: (i) generating, at a first server from the plurality of
servers, a transaction record including data representing the
created policy; (ii) proposing the transaction record to one or
more other servers from the plurality of servers; (iii) performing,
via the plurality of servers, a consensus analysis of the
transaction record utilizing a consensus mechanism; and/or (iv)
when the consensus analysis indicates that the plurality of servers
have formed a consensus, storing the transaction record at the
distributed ledger by storing the transaction record to each copy
of the distributed ledger at the plurality of servers. In one
embodiment, the transaction or another block on the blockchain may
indicate that an individual has a certain type of insurance, such
as auto insurance, and may act as a proof of insurance. The method
may include additional, less, or alternate actions, including those
discussed elsewhere herein.
[0006] 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 THE DRAWINGS
[0007] 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.
[0008] 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:
[0009] FIG. 1A depicts an exemplary database system in accordance
with one aspect of the present disclosure.
[0010] FIG. 1B depicts an exemplary distributed ledger system in
accordance with one aspect of the present disclosure.
[0011] FIG. 1C depicts an exemplary method for adding a transaction
to a distributed ledger in accordance with one aspect of the
present disclosure.
[0012] FIG. 2A depicts an exemplary transaction flow in accordance
with one aspect of the present disclosure.
[0013] FIG. 2B depicts an exemplary block propagation flow in
accordance with one aspect of the present disclosure.
[0014] FIG. 2C depicts an exemplary computer-implemented method for
generating a block in a blockchain in accordance with one aspect of
the present disclosure.
[0015] FIG. 3 depicts an exemplary sequence diagram in accordance
with one aspect of the present disclosure.
[0016] FIG. 4 depicts an exemplary node in accordance with one
aspect of the present disclosure.
[0017] FIG. 5 depicts an exemplary blockchain in accordance with
one aspect of the present disclosure.
[0018] FIG. 6A depicts an example computer-implemented method for
tracking a loss history utilizing a distributed ledger in
accordance with one aspect of the present disclosure.
[0019] FIG. 6B is a block diagram of a client device that may
interact with a distributed ledger system in accordance with one
aspect of the present disclosure.
[0020] FIG. 6C is an exemplary loss history report that may be
generated by a nodes and/or client device in accordance with one
aspect of the present disclosure.
[0021] FIG. 7 depicts, in accordance with one aspect of the present
disclosure, an exemplary computer-implemented method for tracking,
via a distributed ledger, sensor data and other information related
to a claim, such as: an estimated damage, an estimated cost of
repairs, and/or a payment status for a rental vehicle.
[0022] FIG. 8 depicts, in accordance with one aspect of the present
disclosure, an exemplary computer-implemented method for managing,
via a distributed ledger, medical records related to a claim, such
as: an injury description; one or more medical costs; one or more
payout amounts; etc.
[0023] FIG. 9 depicts, in accordance with one aspect of the present
disclosure, an exemplary computer-implemented method for managing,
via a distributed ledger, insurance records, such as: a unique
identifier for the insured; one or more policy numbers associated
with the insured; descriptions of each policy for each policy
number; coverage amounts; etc.
[0024] FIGS. 10-12 and 14 depict exemplary computer-implemented
methods of maintaining a blockchain associated with insured assets
and/or individuals.
[0025] 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
[0026] The present embodiments relate to, inter alia, systems and
methods for using a distributed ledger to record information
related to processes and services in the healthcare, automotive,
and real estate industries. For example, a distributed ledger may
be used to manage: (i) data associated with loss history reports
(for either individuals or insured assets, such as real estate,
vehicles, personal articles, etc.); (ii) data associated with
sensor-based insurance systems; (iii) data associated with medical
record systems; and/or (iv) data associated with insurance record
management systems. In some embodiments, the distributed ledger is
a blockchain system. The systems and methods described herein allow
for using a distributed ledger 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 distributed
ledger.
[0027] 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."
[0028] A blockchain is a 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 transactional records are maintained at each node
of a peer to peer network. Commonly, the distributed ledger is
comprised of groupings of "transactional records" (sometimes simply
referred to as "transactions") bundled together into a "block."
Generally speaking, each "transaction" or "transactional record" is
a record of an update or change made to the distributed ledger. The
nature of the information included in each transactional record
generally depends on the particular implementation of a given
distributed ledger, and on the information the distributed ledger
is intended to track.
[0029] 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 may use 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 immutable.
[0030] Some blockchains may be 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, such as information related to a vehicle lifecycle
process, or for interactions that require all participants to be
vetted prior to their participation.
[0031] In any event, 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 data storage and
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 may
be 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.
[0032] According to certain aspects disclosed herein, information
stored in blockchains may 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).
[0033] 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 valid. Since the solution depends on the
particular hash values for each transaction within the blockchain,
if the solving node attempted to modify any transaction stored in
the blockchain, the solution would not be verified by the other
nodes. More specifically, if a single node attempts to modify a
prior transaction within the blockchain, a cascade of different
hash values may be 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.
Exemplary Database & Distributed Ledger
[0034] FIG. 1A depicts an exemplary central authority database
system 100 in accordance with one aspect of the present disclosure.
Figure lA includes a central authority 101; a plurality of nodes
103, 105, and 107; a central ledger 109; and a plurality of network
connections 111. In one exemplary operation of the database system
100, one of the nodes, for example node 103, issues a request to
the central authority 101 to perform an action on data stored in
the central ledger 109. This request may be a request to create,
read, update, or delete data that is stored in the central ledger
109.
[0035] In such an example, the central authority 101 receives the
request, processes the request, makes any necessary changes to the
data stored in the central ledger 109, and informs the requesting
node (node 103) of the status of the request. The central authority
101 may also send out status updates to the other nodes on the
network about the change made, if any, to the data by node 103. In
the database system 100, all interaction with the data stored in
the central ledger 109 occurs through the central authority 101. In
this way, the central authority functions as a gatekeeper of the
data.
[0036] Accordingly, the central authority 101 may operate as a
single point of entry for interacting with the data, and
consequently the central authority 101 is a single point of failure
for the entire database system 100. As such, if the central
authority 101 is not accessible to the nodes in the database system
100, then the data stored in the central ledger 109 is not
accessible.
[0037] In another example, each individual node may keep its own
databases and may periodically send a copy of its database to the
central authority 101, where the received databases are reconciled
to form a single cohesive record of the data stored in the central
ledger 109.
[0038] Conversely, FIG. 1B depicts an exemplary distributed ledger
system 112 in accordance with an 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 102,
104, and 106; a distributed ledger 114; and a plurality of network
connections 110. In the distributed ledger system 112, each node
keeps a copy of the distributed ledger 114.
[0039] Each copy of the distributed ledger 114 maintains a copy of
a plurality of transactions 116-126 tracked in the distributed
ledger 114. Generally speaking, each of the transactions 116-126
(sometimes referred to as a "transactional records" or "transaction
records") is a record of an update or change made to the
distributed ledger 114. The nature of the information included in
each transactional record 116-126 generally depends on the
particular implementation of the distributed ledger 114, and on the
information the distributed ledger 114 is intended to track.
[0040] As changes are made to the distributed ledger 114, each node
102-106 updates its copy of the distributed ledger 114. A consensus
mechanism (sometimes referred to as a consensus protocol) 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. Example consensus mechanisms that may be used by the
distributed ledger 114 include: proof of work, proof of stake,
proof of activity, proof of burn, proof of capacity, and/or proof
of elapsed time. Therefore, each node has its 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 such as the system 100 shown in FIG. 1A,
because the distributed ledger system 112 is decentralized and no
single point of failure exists.
[0041] The system 112 and distributed ledger 114 may be implemented
using a number of different blockchain protocols, depending on the
embodiment. Example blockchain protocols that may be implemented
include: Hyperledger Fabric, Ethereum, Corda, Ripple, ZCash, and
Sawtooth. For example, the method 600 described with reference to
FIG. 6A may be implemented to track loss history using the
distributed ledger 114 in one embodiment in which the distributed
ledger 114 is configured to utilize the Hyperledger Fabric
protocol.
[0042] FIG. 1C is a flow chart of an exemplary computer-implemented
method 150 for adding a transaction to the distributed ledger 114
in accordance with one aspect of the present disclosure. The method
150 may be implemented, in whole or in part, by the nodes 102-106
in the system 112 shown in FIG. 1B, and may be saved to a memory of
one or more of the nodes as one or more instructions or routines
executable by a processor.
[0043] The method 150 begins when a node proposes a transaction
(block 152). The nature of the transaction depends on the
implementation. In one embodiment, the ledger 114 tracks loss
history for properties and each transaction represents a claim
filed against a particular property. In such an embodiment, a new
transaction might be proposed when an insurance company receives or
completes a claim filed against a particular property. The
transaction might include data about the property (e.g., property
type, address of a home, make and model of a vehicle, etc.), owner
(e.g., name, social security number, etc.), and/or claim (damage
type, estimated loss, claim payout amount, etc.).
[0044] One or more other nodes in the system 112 may receive the
proposed transaction and attempt to form a consensus in order to
verify the validity of the transaction (block 154). The nodes may
utilize a proof of work consensus protocol such as that already
described. If the nodes are unable to reach consensus, the
transaction is not added to the ledger 114. When the nodes reach
consensus, the transaction is added to the distributed ledger 156.
That is, a copy of the transaction is added to each copy of the
ledger 114 held at each node 102-106. Accordingly, the nodes
102-106 are able to maintain identical copies of the ledger 114,
thus maintaining consistency and accuracy of the ledger 114 without
a single central authority.
Exemplary Transaction Flow & Block Propagation Flow
[0045] FIG. 2A depicts an exemplary transaction flow 200 in
accordance with one aspect of the present disclosure. FIG. 2A
includes a transactional record ("transaction") 202; three
different time frames 204, 206, and 208; the nodes 102-106; the
network connections 110; and the distributed ledger 114. The
transaction flow 200 may represent a sequential flow of the
transaction 202 through a network (such as the network depicted in
FIG. 1B).
[0046] In the shown example, the node 102 generates the transaction
202 at time 204. The transaction 202 may include data that is
stored in the distributed ledger 114 at the node 102, or may
include data received by the node 102 from outside the distributed
ledger 114. The node 102 may transmit the newly generated
transaction 202 to node 106 via the network connection 110.
[0047] At time 206, the node 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, the
node 106 may reject the transaction and not propagate the
transaction 202 through the system. If the information contained in
the transaction 202 is correct, the node 106 may transmit the
transaction 202 to the node 104.
[0048] At time 208, the node 104 may receive the transaction 202
and may confirm or reject the transaction 202. In some embodiments,
the node 104 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.
[0049] 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 114. In some embodiments,
confirming the transaction 202 includes checking cryptographic
key-pairs for participants involved in the transaction 202.
Checking the cryptographic key-pairs may follow a method laid out
by a consensus protocol, such as the consensus protocol discussed
in FIG. 1B.
[0050] FIG. 2B depicts an exemplary block propagation flow 210 in
accordance with one aspect of the present disclosure. FIG. 2B
includes two time frames 212 and 214; the node 106 and the node
104; the transactions 116-122; a set of blocks of transactions
216A-216D; the distributed ledger 114; and a blockchain 218. The
block propagation flow 210 may follow the blockchain system
described above, or may follow another blockchain propagation
algorithm.
[0051] The block propagation flow 210 may begin with the node 106
receiving the transaction 116 at time 212. When node 106 confirms
that the transaction 116 is valid, the node 106 may add the
transaction 116 to the block 216A (which may be newly generated).
As part of adding the transaction 116 to the block 216A, node 106
may solve a cryptographic puzzle and include the solution in the
newly generated block 216A as proof of the work done to generate
the block 216A. 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 116 may be added to a pool of
transactions until enough transactions exist to form a block. Node
106 may transmit the newly created block 216A to the network at
220. Before or after propagating the block 216A, node 106 may add
the block 216A to its copy of the blockchain 218.
[0052] At time 214, node 104 may receive the block 216A. Node 104
may verify that the block 216A is valid by checking the solution to
the cryptographic puzzle provided in the block 216A. If the
solution is accurate, then the node 104 may add the block 216A to
its blockchain 218 and transmit the block 216A to the rest of the
network at 222.
[0053] In one embodiment, one or more transactions 202 or events
may relate to: smart contracts, loss history and loss history
reports, insurance claims, vehicle sensor data, medical records,
and/or insurance records.
[0054] FIG. 2C depicts an exemplary method 230 for generating the
block 216C shown in FIG. 2B, according to one embodiment. The
method 230 may be implemented by a processor of one or more of the
nodes 102-106, and may be implemented as part of a consensus
mechanism. It will be understood that the method 230 is exemplary,
and not every embodiment implements the method 230.
[0055] In the method 230, a processor generates hash values
116A-122A for each of the transactions 116-122, using data
associated with each of the transactions 116-122 as inputs for a
hash function (step 232). The processor then generates a hash value
117 using the hash values 116A and 118A as inputs for the hash
function, and a hash value 121 using the hash values 120A and 122A
as inputs for the hash function (step 234). Finally, when
generating block 216C, a hash for block 216 is generated using as
inputs: a hash value of the "chained" block 216B, the hash vales
117 and 121, and a nonce value (step 236). Because every other node
may have access to the block 216B and to the transactions 116-122,
when a node publishes that a cryptographic puzzle has been solved
utilizing the nonce value, the other nodes can confirm whether or
not the solution is valid (because a change to any transaction
116-122, or to any transaction in block 216B, or to the nonce
value, will result in a different hash value for block 216C).
Exemplary Sequence Diagram
[0056] FIG. 3 depicts an exemplary sequence diagram 300 in
accordance with one aspect of the present disclosure. FIG. 3
includes the set of nodes 102, 104, and 106. At time 302, the node
102 may generate a transaction. At time 304, the transaction may be
transmitted from the node 102 to the node 106. At time 306, the
node 106 may validate the transaction. At time 308, if the
transaction is valid, the node 106 may transmit the transaction to
node 104. At time 310, node 104 may validate the transaction. At
time 312, the node 106 may compile a block 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. At time 314, once the block is
compiled, the node 106 may transmit the block with the solution to
both the node 102 and the node 104.
[0057] At time 316, both nodes may validate the solution to the
block. Verifying may include checking a cryptographic key-pair as
described above. At time 318, the three nodes form a consensus that
the solution is valid. Accordingly, in the shown example, all the
nodes have formed a consensus on the blocks of transactions stored
by all the nodes.
Exemplary Node
[0058] FIG. 4 is a block diagram of the node 102, according to one
embodiment. It will be understood that the nodes 104 and 106 may
perform one or more of the functions that the node 102 is capable
of performing, and may include one or more of the components
included in the node 102. The node 102 may utilize the
decentralized system 112 described with respect to FIG. 1B, the
flows 200 and 210 of transactions and blocks described in FIGS. 2A
and 2B, and/or the blockchain system 500 described below with
reference to FIG. 5.
[0059] The node 102 includes one or more of the following: at least
one processor 402, memory 404, a communication module 406, a set of
applications 408, one or more external ports 410, a user interface
412, a blockchain manager 414, smart contracts 416, an operating
system 418, a display screen 420, and input/output components 422.
In some embodiments, the node 102 may generate a new block of
transactions using the blockchain manager 414. Similarly, the node
102 may use the blockchain manager 414 in conjunction with the
smart contracts 416 stored in memory 404 to execute the
functionality disclosed herein.
[0060] In some embodiments, the smart contracts 416 operate
independent of the blockchain manager 414 or other applications. In
some embodiments, the node 102 does not include one or more of the
blockchain manager 414 or the smart contracts 416. In some
embodiments, the node 102 may have additional or less components
than what is described. The smart contracts may relate to, or be
associated with, insureds and/or insured assets, including smart
insurance contracts, smart maintenance contracts, smart health care
contracts, smart repair or upkeep contracts, etc.
[0061] The node 102, 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 tracking loss history, vehicle sensor
data, medical records, and/or insurance records.
Exemplary Blockchain System
[0062] FIG. 5 depicts an exemplary blockchain system 500 in
accordance with an aspect of the present disclosure. The system 500
includes a blockchain 502 that includes one or more blocks,
including a block of transactions 504. The block 504 includes a
Merkle Tree 506 that includes one or more transactions, including a
transaction 508 that includes data 510. The Merkle Tree 506 may be
the same Merkle Tree referred to above that cryptographically links
transactions together. In some embodiments, the blockchain system
500 may utilize other methods of organizing transactions in a
block.
[0063] As noted, the block of transactions 504 includes the
transaction 508, but may also include other transactions in some
instances. In some embodiments, the block of transactions 504 has a
size limit limiting the number of transactions that the block 504
may store. In one exemplary implementation, the block 504 includes
a reference to a previous block of transactions that was added to
the blockchain 502 prior to the block 504 being added to the
blockchain 502. As such, and as described above, each block in the
blockchain 502 is linked to every other block in the blockchain
502.
[0064] 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 may be
stored in the tree. As the tree is constructed, the hash of each
adjacent node at the same level 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 below in the tree. Each
transaction 508 may include a set of data 510. The set of data 510
may include an identifier for the transaction (e.g., a unique
string), and transaction data identifying the nature of the
transaction and what the transactions entails.
[0065] In some embodiments, the blockchain 218 shown in FIG. 2B may
be similar to the blockchain 502, and the transactions 116-126
shown in FIG. 1B and 2B may be similar to the transaction 508. In
some embodiments, the ledger 114 may share some of the
functionality of the system 500, as well as the organization of
blocks and transactions.
Loss History Reports
[0066] In one embodiment, a distributed ledger is utilized to track
insurance claims and to generate loss history reports. The present
embodiments may be configured to track all insurance claims
relating to a particular person and/or property (e.g., a home,
automobile, personal articles, or other insured assets), develop
one or more loss histories and store them on a blockchain.
[0067] In one embodiment, the distributed ledger system 112 shown
in FIG. 1B may be utilized to track insurance claims.
Advantageously, such a system enables the insurance companies to
eliminate the third party typically responsible for maintaining the
centralized database. Multiple insurance companies may maintain a
local copy of the distributed ledger 114. For example, Alpha
Insurance Company ("Alpha") may maintain a local copy of the ledger
114 at the node 102, Bravo Insurance Company ("Bravo") may maintain
a local copy of the ledger 114 at the node 104, and Charlie
Insurance Company ("Charlie") may maintain a local copy of the
ledger 114 at the node 106.
[0068] Each transaction stored at the ledger 114 may represent a
filed claim, and may include data representing one or more of the
following items: a unique transaction identifier; an identifier for
the insured (e.g., unique identifier and/or name of the insured);
an address for the insured; a birth date for the insured; a social
security number for the insured; a name of the insurance company
receiving the claim; an indication of the type of insurance policy
held by the insured; an insurance policy number; an identifier for
the type of loss (e.g., indicating fire damage, water damage, hail
damage, etc.); the date of the loss; the monetary loss for the
claim; the status of the claim; and information associated with one
or more smart contracts, such as a smart insurance contract.
[0069] FIG. 6A depicts an exemplary computer-implemented method 600
for tracking a loss history utilizing a distributed ledger. The
method 600 may be implemented, in whole or in part, by the system
112 shown in FIG. 1B. The method 600 may be saved to a memory as
one or more instructions or routines.
[0070] The method 600 begins when someone files a claim with Alpha
(block 602). After Alpha receives the claim, the node 102 generates
a transaction including information pertaining to the claim and
proposes the transaction by transmitting the transaction to nodes
104 and/or 106 (block 604). The nodes 102, 104, and 106 then
attempt to form a consensus, using any suitable consensus protocol
(such as the hashing and problem solving technique previously
described) as to whether the transaction is valid (block 606). In
instances when consensus is not reached, the proposed transaction
is not added to the ledger 114m and notification that the
transaction is invalid may be generated (block 608).
[0071] When consensus is reached, each of the nodes 102, 104, and
106 adds the transaction to a block (block 610), and the block, if
not already part of the blockchain, is added to the blockchain
(block 616) stored at the distributed ledger 114. Advantageously,
after the blockchain has been updated, each of the nodes 102, 104,
and 106 can access and review the transaction including the
information pertaining to the new claim. Indeed, in one embodiment,
any party having access and permission to the blockchain at the
ledger 114 may easily generate a report by reviewing, via the
ledger 114, all claims associated with a particular property.
Consequently, the method 600 eliminates the need for a third party
intermediary that aggregates claim histories from multiple
insurance company.
[0072] FIG. 6B is a block diagram of a client device 650 that may
interact with the system 112 in one embodiment. The client device
650 may include a processor 652 and one or more of the following,
which may be connected to the processor 652 via a system bus: a
memory 654 including a client application 674, a communication
module 656, external ports 660, and a user interface 662. The user
interface 662 may include a display screen 670 and/or other I/O
components 672. The communication module 656 may be communicatively
coupled to the distributed ledger system 112 shown in FIG. 1B,
enabling the client device 650 to communicate with one or more of
the nodes 102-106 and to access to the distributed ledger 114.
[0073] In example operation, the processor 652 executes the client
674, causing the client device 650 to communicate with the system
112 via the communication module 656. The client device 650 may
transmit a request for a loss history report pertaining to a
particular individual.
[0074] The client device 650 may transmit a unique identifier for
the individual. In response, one of the nodes 102-106 responds by
transmitting a report including the pertinent transaction records
for all insurance claims for the individual of interest after
performing a lookup on a local copy of the distributed ledger
114.
[0075] In one embodiment, the client device 650 is part of the
system 112. For example, the memory 654 may include a copy of the
distributed ledger 114 and/or the blockchain manager 414. In such
instances, the client device 50 is a node of the system 112, and
thus may be considered a server hosting a copy of the ledger 114.
In such an embodiment, when a user of the client device 650
requests a loss history report via the user interface 662, the
processor 652 retrieves the pertinent transaction records for all
insurance claims for the individual of interest from a copy of the
distributed ledger 114 stored at the memory 654.
[0076] FIG. 6C is an example loss history report 680 that may be
generated by one of the nodes 102-106 and/or client device 650 in
one embodiment. The lost history report 680 may be displayed on a
display device such as the screen 670 and/or may be printed. The
loss history report 680 may be generated in response to a request
submitted by a user via the user interface 662 of the client device
650 and transmitted to the distributed ledger system 112 via the
communication module 656.
[0077] The loss history report 680 may include: a date of order 681
indicating a date on which the report 680 was ordered; a date of
receipt 682 indicating a date on which the report 680 was received;
a reference number 683 unique to the report 680 (this may be useful
if multiple reports are pulled on a single property); a recap 684
identifying a number of claims reported on the property or person
searched; and a search summary 685. The search summary 685 may
identify a person and/or property being searched; a person who owns
the property being searched; a date of birth for the person; a
unique identifier, such as a social security number, for the
person, a sex of the person; and/or a telephone number for the
person. The property may be a real estate property, such as a home
or office building. In some embodiments, the property is personal
property, such as a vehicle, jewelry, electronics, paintings,
antiques, and/or other personal belongings or insured assets.
[0078] The loss history report 680 may list all recent insurance
claims filed by an individual or insured, and/or all recent
insurance-related transactions associated with the individual or
insured.
[0079] In other words, the report may be individual-based or
individual centric. The loss history report 680 may additionally or
alternatively list all recent insurance claims filed associated
with an insured asset, such as a vehicle or home, and/or all recent
insurance-related transactions associated with the insured asset.
In other words, the report may be insurable-asset based or
insurable-asset centric.
Sensor-Based Insurance Systems
[0080] In one embodiment, a distributed ledger is utilized manage
data associated with sensor-based insurance systems. While some
vehicle systems collect certain types of sensor data, this sensor
data is generally locally available to an in-vehicle computer. In
some instances, the sensor data may be uploaded to a centralized
server (e.g., maintained by an insurance company for the purpose of
monitoring driving habits).
[0081] FIG. 7 depicts an exemplary computer-implemented method 700
for tracking, via a distributed ledger, sensor data and other
information related to a claim, such as: an estimated damage, an
estimated cost of repairs, and/or a payment status for a rental
vehicle. The method 700 may be implemented, in whole or in part, by
the system 112 shown in FIG. 1B. The method 700 may be saved to a
memory as one or more instructions or routines.
[0082] The method 700 begins when a collision is detected (block
702). The collision may be detected from various types of sensor
and vehicle data, such as data collected via any of a number of
suitable sensors at a vehicle, including accelerometers,
speedometers, GPS sensors, impact sensors, etc. The sensor and
vehicle data may include telematics data (which may include speed,
GPS, heading, route, cornering, braking, acceleration,
deceleration, and other types of information). The sensor and
vehicle data may include mobile device sensor data, which may
include some types of telematics data. The sensor and vehicle data
may include image, radar, telematics, and other data collected by
one or more smart or autonomous vehicles, such as there may several
vehicles in the vicinity of a vehicle collision at the time of
collision, and sensor data from the several vehicles may be
collected, and analyzed.
[0083] After detecting the collision, the node 102 (which may be a
computer installed in the vehicle or a mobile device such as a
tablet or smart phone, depending on the embodiment) generates a
transaction including sensor data pertaining to the collision. In a
manner similar to that described with reference to blocks 604-616,
the transaction is proposed, the nodes attempt to reach consensus,
and the transaction is added to the ledger 114 when consensus is
reached (blocks 704-716).
[0084] Advantageously, after the ledger 114 has been updated, each
of the nodes 102, 104, and 106 can access and review the
transaction including the sensor data and associated information
pertaining to a claim. One or more systems may access the ledger
114 to estimate damage and/or cost of repairs based upon the sensor
data, and may similarly update the ledger 114 to include this
information. Notably, the method 700 gives a user access to data
relating to his or her collision; he or she may not have to
interact with a gatekeeper responsible for maintaining information
at a centralized database.
[0085] In another example, one or more home-based "smart devices,"
claim assessment drones, and/or an insurance company may utilize
the ledger 114 to track information related to a real estate claim,
such as: estimated damage to a home, estimated repair costs,
payouts associated with the claim, third parties to be receive
payouts, etc.
[0086] In yet another example, one or more vehicles and an
insurance company may utilize the ledger 114 to track sensor data
for the purpose of updating a UBI profile. Such an example
similarly offers a user the advantage of having access to his or
her data that might otherwise be stored at a centralized
database.
Medical Record Systems
[0087] In one embodiment, a distributed ledger is utilized manage
medical record systems. Currently, medical records are often held
by a multitude of different institutions, each of which maintains
its own centralized database including an incomplete record of a
patient's medical history (e.g., relating to only a certain period
of time or to certain specialty procedures). By contrast, the
disclosed system enables aggregation of a complete medical history
(to the extent desired), and gives a patient access to records of
his or her medical records. In particular, the disclosed system may
be utilized to track medical records associated with particular
insurance claims.
[0088] FIG. 8 depicts an example method 800 for managing, via a
distributed ledger, medical records related to a claim, such as: an
injury description; one or more medical costs; one or more payout
amounts; etc. The method 800 may be implemented, in whole or in
part, by the system 112 shown in FIG. 1B. The method 800 may be
saved to a memory as one or more instructions or routines.
[0089] The method 800 begins when a claim is filed (e.g., after a
vehicle collision) (block 802). After the claim is received, the
node 102 generates a transaction including data pertaining to the
claim, and more particularly, to medical records associated with an
injury resulting from the event that led to the claim. In a manner
similar to that described with reference to blocks 604-616, the
transaction is proposed, the nodes attempt to reach consensus, and
the transaction is added to the ledger 114 when consensus is
reached (blocks 804-816).
[0090] One or more systems may access the ledger 114 to facilitate
processing a claim associated with the transaction. Further, the
method 800 gives a patient and/or an insurance company (when
permitted) access to his or her medical records, which typically is
maintained at a centralized database at a health care institution
or at a service provider associated with the health care
institution.
Insurance Record Management Systems
[0091] In one embodiment, a distributed ledger may be utilized to
manage insurance record management systems. Currently, insurance
records are generally held by individual insurance companies and
are not readily available to third parties who wish, for example,
to verify that a person is currently insured. By contrast, the
disclosed system may manage insurance records via a distributed
ledger, enabling multiple parties to easily verify a person's
insurance policy.
[0092] FIG. 9 depicts an exemplary computer-implemented method 900
for managing, via a distributed ledger, insurance records, such as:
a unique identifier for the insured; one or more policy numbers
associated with the insured; descriptions of each policy for each
policy number; coverage amounts; etc. The method 900 may be
implemented, in whole or in part, by the system 112 shown in FIG.
1B. The method 900 may be saved to a memory as one or more
instructions or routines.
[0093] The method 900 may begin when an insurance policy is
generated for someone (block 902). The generated policy could be
for any suitable insurance product, such as home insurance, vehicle
insurance, umbrella insurance, life insurance, etc. After the
policy is generated, the node 102 generates a transaction including
data pertaining to the policy. In a manner similar to that
described with reference to blocks 604-616, the transaction is
proposed, the nodes attempt to reach consensus, and the transaction
is added to the ledger 114 when consensus is reached (blocks
904-916).
[0094] One or more systems may access the ledger 114 to lookup
information pertaining to someone's insurance. For example, when a
driver is pulled over by law enforcement for speeding, he or she
may wish to verify his insurance policy by granting a law
enforcement official permission to view his or her insurance
records stored on the ledger 114. Advantageously, the method 900
could consequently eliminate the need to carry physical proof of
insurance. Further, the method 900 could be utilized to make the
exchange of insurance information after an accident more
efficient.
Additional Exemplary Loss History
[0095] In the insurance industry, loss history may have several
meanings. Loss history may include or comprise a report detailing
information or data from multiple insurers about an individual's
insurance claim history and other asset/insured related
information. For instance, loss history may detail the insurance
claims filed or reported by an insured, or insurance claims filed
relating to an insured asset, such as an automobile or home.
[0096] Insurance provider remote servers may report their data to a
private or public blockchain, and then the blockchain may generate
a consumer's history report independently of 3rd party data
aggregators. For instance, the blockchain may include up-to-date
information about an insured vehicle, an insured home, other
insured assets, and/or about individual customers. The information
maintained on the block may include insurance claim information,
including amount of claim, and various types of sensor information
(telematics, smart vehicle, mobile device, smart home, smart
infrastructure, and other sensor data).
[0097] Insurance provider remote servers may submit information to
the blockchain on real-time or periodic basis. In one embodiment,
insurance companies may request data by forwarding search criteria
such as an insurance applicant's name, date of birth, risk address,
social security numbers (SSNs), etc. An electronic search tool or
engine may search a shared ledger for information that matches the
requested search criteria and delivers results of the search.
[0098] In one aspect, the blockchain may act as an event registry
that updates information on the blockchain each time there is an
event. For instance, a vehicle-based blockchain may update
information each time there is new information, or a change in
information, related to the vehicle owner, the insured, or the
vehicle, including change of addresses, new insurance claims,
vehicle maintenance/repair events, etc. As another example, a
home-based blockchain update information on the chain each time
there is new information, or a change in information, related to
the home or the homeowner (or the insured), including payment of
taxes and/or insurance, and/or new insurance claims and home
repairs/maintenance.
Exemplary Methods of Maintaining a Blockchain
[0099] FIG. 10 depicts an exemplary computer-implemented method of
maintaining a blockchain on insured assets or individuals 1000. The
method 1000 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (1) receiving a
notification of, or associated with, a change in information
associated with an insured and/or an insured vehicle, insured home,
insured personal articles, and/or other insured assets 1002; and/or
(2) receiving a notification of, or associated with, a loss
associated with an insured, or an insured vehicle, insured home,
insured personal articles, and/or other insured assets 1004. The
notification of loss may include loss information, claim
information, various sensor data, telematics data, autonomous
vehicle sensor or other data, intelligent home sensor or other
data, mobile device data, and/or other data about insureds and
insured assets, including that discussed elsewhere herein). For
instance, the notifications may be received via wireless
communication or data transmission over one or more radio frequency
links or digital communication channels, and stored in a local
memory.
[0100] The method 1000 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (3) identifying
and/or accessing a blockchain using an identifier associated with
both the blockchain and an insured and/or insured asset 1006. For
instance, a VIN (Vehicle Identification Number) may be used to
identify and/or access an insured vehicle and an associated
blockchain. A SSN may be used to identify and/or access an insured
and an associated blockchain. An address, MLS listing, or tax
parcel number may be used to identify and/or access an insured home
and an associated blockchain. In some embodiments, the identifiers
may hashed and/or encrypted, along with other data and/or blocks
within the blockchain.
[0101] The method 1000 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (4) creating a
new block using the new information (or changed information) and/or
the notification of loss information, and/or an amount of loss and
other loss information 1008. The method 1000 may include, via one
or more local or remote processors, sensors, servers, and/or
transceivers, (5) transmitting the new block to a network of nodes
to form a consensus among the nodes as whether or not to update the
blockchain 1010. For instance, the new block may be transmitted to
other nodes within a network via wireless communication or data
transmission over one or more radio links.
[0102] The method 1000 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (6) receiving or
determining when a consensus is formed from communicating with
other nodes in the networks 1012. When a consensus if formed, the
method 1000 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (7) updating the
blockchain, on each node, with the new block 1014, and (8) handling
or updating an insurance claim for an insured asset, and/or
facilitating repairs for an insured asset 1016 if not yet performed
or still necessary. The method may include additional, less, or
alternate actions, including those discussed elsewhere herein,
and/or may be carried out by computer systems comprising of one or
more processors, servers, sensors, and/or transceivers configured
to perform the functionality and/or via computer-executable
instructions stored on computer readable medium or media.
[0103] FIG. 11 depicts another exemplary computer-implemented
method of maintaining a blockchain associated with insured assets
and/or individuals 1100. The method 1100 may include, via one or
more local or remote processors, sensors, servers, and/or
transceivers, (1) receiving a notification of, or associated with,
a change in information associated with an insured and/or an
insured vehicle, insured home, insured personal articles, and/or
other insured assets 1102; and/or (2) receiving a notification of,
or associated with, a loss associated with an insured, or an
insured vehicle, insured home, insured personal articles, and/or
other insured assets 1104. The notification of loss may include
loss information, claim information, various sensor data,
telematics data, autonomous vehicle sensor or other data,
intelligent home sensor or other data, mobile device data, and/or
other data about insureds and insured assets, including that
discussed elsewhere herein). For instance, the notifications may be
received via wireless communication or data transmission over one
or more radio frequency links or digital communication channels,
and stored in a local memory.
[0104] The method 1100 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (3) identifying
and/or accessing a blockchain using an identifier associated with
both the blockchain and an insured and/or insured asset 1106. For
instance, a VIN (Vehicle Identification Number) may be used to
identify and/or access an insured vehicle and an associated
blockchain. A SSN may be used to identify and/or access an insured
and an associated blockchain. An address, MLS listing, or tax
parcel number may be used to identify and/or access an insured home
and an associated blockchain. In some embodiments, the identifiers
may hashed and/or encrypted, along with other data and/or blocks
within the blockchain.
[0105] The method 1100 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (4) receiving or
retrieving from a memory new information associated with a change
in information and/or a notification of loss (and/or amount and
type of loss) 1408. The method 1100 may include, via one or more
local or remote processors, sensors, servers, and/or transceivers,
(5) transmitting the new information to a network of nodes to form
a consensus among the nodes as whether or not to update the
blockchain 1110. For instance, the new block may be transmitted to
other nodes within a network via wireless communication or data
transmission over one or more radio links.
[0106] The method 1100 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (6) receiving or
determining when a consensus is formed from communicating with
other nodes in the networks 1112. When a consensus if formed, the
method 1100 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (7) creating a
new block using the new information (or changed information) and/or
the notification of loss information, and/or an amount of loss and
other loss information 1114, and (8) updating the blockchain, on
each node, with the new block 1116, or otherwise updating the
blockchain on each node with the new information. The method 1100
may also include, via one or more local or remote processors,
sensors, servers, and/or transceivers, (9) handling or updating an
insurance claim for an insured asset, and/or facilitating repairs
for an insured asset 1118 if not yet performed or still necessary.
The method may include additional, less, or alternate actions,
including that discussed elsewhere herein, and/or may be carried
out by computer systems comprising of one or more processors,
servers, sensors, and/or transceivers configured to perform the
functionality and/or via computer-executable instructions stored on
computer readable medium or media.
[0107] FIG. 12 depicts another exemplary computer-implemented
method of maintaining a blockchain associated with insured assets
and/or individuals 1200. The method 1200 may include, via one or
more local or remote processors, sensors, servers, and/or
transceivers, (1) receiving a notification of, or associated with,
a change in information associated with an insured and/or an
insured vehicle, insured home, insured personal articles, and/or
other insured assets 1202, such as from a node associated with an
insurance provider or from an insurance provider remote server. For
instance, the notifications may be received via wireless
communication or data transmission over one or more radio frequency
links or digital communication channels, and stored in a local
memory.
[0108] The method 1200 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (2) identifying
and/or accessing a blockchain using an identifier associated with
both the blockchain and an insured and/or insured asset 1204. For
instance, a VIN (Vehicle Identification Number) may be used to
identify and/or access an insured vehicle and an associated
blockchain. A SSN may be used to identify and/or access an insured
and an associated blockchain. An address, MLS listing, or tax
parcel number may be used to identify and/or access an insured home
and an associated blockchain. In some embodiments, the identifiers
may hashed and/or encrypted, along with other data and/or blocks
within the blockchain.
[0109] The method 1200 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (3) receiving or
retrieving from a memory new information associated with a change
in information and/or a change in carrier (or otherwise a new
carrier) 1506. The method 1200 may include, via one or more local
or remote processors, sensors, servers, and/or transceivers, (4)
transmitting the new information (such as identification of a new
carrier and/or new policy information) to a network of nodes to
form a consensus among the nodes as whether or not to update the
blockchain 1208. For instance, the new block may be transmitted to
other nodes within a network via wireless communication or data
transmission over one or more radio links.
[0110] The method 1200 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (5) receiving or
determining when a consensus is formed from communicating with
other nodes in the networks 1210. When a consensus if formed, the
method 1200 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (6) creating a
new block using the new information (or changed information) and/or
the new insurance carrier and/or new insurance policy information
1212, and/or (7) updating the blockchain, on each node, with the
new block 1214, or otherwise updating the blockchain on each node
with the new information. The method 1200 may also include handling
or updating an insurance claim for an insured asset, and/or
facilitating repairs for an insured asset if not yet performed or
still necessary. The method may include additional, less, or
alternate actions, including that discussed elsewhere herein,
and/or may be carried out by computer systems comprising of one or
more processors, servers, sensors, and/or transceivers configured
to perform the functionality and/or via computer-executable
instructions stored on computer readable medium or media.
[0111] FIG. 14 depicts another exemplary computer-implemented
method of maintaining a blockchain on insured assets or individuals
1400. The method 1400 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (1) receiving a
notification of, or associated with, an insurance claim associated
with an insured and/or an insured vehicle, insured home, insured
personal articles, and/or other insured assets, and/or receiving
insurance claim related data 1402, such as from a node associated
with an insurance provider or from an insurance provider remote
server. For instance, the notifications may be received via
wireless communication or data transmission over one or more radio
frequency links or digital communication channels, and stored in a
local memory.
[0112] The method 1400 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (2) identifying
and/or accessing a blockchain using an identifier associated with
both the blockchain and an insured and/or insured asset 1404. For
instance, a VIN (Vehicle Identification Number) may be used to
identify and/or access an insured vehicle and an associated
blockchain. A SSN may be used to identify and/or access an insured
and an associated blockchain. An address, MLS listing, or tax
parcel number may be used to identify and/or access an insured home
and an associated blockchain. In some embodiments, the identifiers
may hashed and/or encrypted, along with other data and/or blocks
within the blockchain.
[0113] The method 1400 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (3) receiving or
retrieving from a memory new information associated with an
insurance claim and/or an amount associated with an insurance claim
1406. The method 1400 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (4) transmitting
the new information (such as identification of a new insurance
claim and policy information) to a network of nodes to form a
consensus among the nodes as whether or not to update the
blockchain 1408. For instance, the new block may be transmitted to
other nodes within a network via wireless communication or data
transmission over one or more radio links.
[0114] The method 1400 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (5) receiving or
determining when a consensus is formed from communicating with
other nodes in the networks 1410. When a consensus if formed, the
method 1400 may include, via one or more local or remote
processors, sensors, servers, and/or transceivers, (6) creating a
new block using the new insurance claim data and/or policy data
1412, and/or (7) updating the blockchain, on each node, with the
new block 1414, or otherwise updating the blockchain on each node
with the new insurance claim information. The method 1400 may also
include handling or updating an insurance claim for an insured
asset, and/or facilitating repairs for an insured asset if not yet
performed or still necessary. The method may include additional,
less, or alternate actions, including that discussed elsewhere
herein, and/or may be carried out by computer systems comprising of
one or more processors, servers, sensors, and/or transceivers
configured to perform the functionality and/or via
computer-executable instructions stored on computer readable medium
or media.
[0115] In one exemplary flow, a computer-implemented method may
include (1) receiving, at a processor coupled with a network
interface (such as via wireless communication or data transmission
over one or more radio links), an insurance claim notification from
at least a first participant, wherein the claim notification
comprises an insured asset identifier, and an insured asset owner
identifier; (2) retrieving or accessing, at a memory coupled with a
processor, the blockchain using the insured asset identifier and/or
insured asset owner identifier. The method may include (3)
updating, at the memory, a block stored at the memory using the
insured asset identifier and/or insured asset owner identifier; and
(4) transmitting, via the processor coupled with the network
interface (such as via wireless communication or data transmission
over one or more radio links), the block to at least a second
participant or node within a private or public communication
network.
[0116] In some embodiments, insured asset may be a vehicle, a home,
or a personal article. The first participant or node may be a
sensor, a sensor system, or computer system attached to the insured
asset, such as an autonomous vehicle technology system mounted on a
vehicle. In other embodiments, the first participant or node may be
a repair shop server or computer system. Similarly, in some
embodiments, accessing the blockchain using the insured asset
identifier or the insured identified may include searching, at the
processor, the blockchain using the insured asset identifier or
insured identifier for a block or blockchain that includes the
insured asset identifier or insured identifier; and verifying, at
the processor, the insured asset identifier or insured identifier
stored at the block.
[0117] In other embodiments, if the insured asset identifier is not
stored at a block, the method may include generating, at the
processor, an insured asset record using the insured asset
identifier; adding, at the processor, the insured asset identifier
and the insured identifier to an insured asset transaction; adding,
at the processor, the insured asset transaction to a set of insured
asset loss or other transactions; and adding, at the processor, the
set of insured asset loss or other transactions to the block.
[0118] In other embodiments, the method may include solving, at the
processor, a cryptographic puzzle corresponding to the block; and
adding, at the processor, the solution to the cryptographic puzzle
to the block. Additionally, in some embodiments, updating, at the
memory, the blockchain by adding the block to the blockchain.
[0119] In yet other embodiments of the method, the at least one
other participant is an insurer, a vehicle owner, a repair shop, or
combinations thereof. In some embodiments, the method may include
receiving, at the processor, a repair notification from one or more
remote servers associated with other parties, such as repair shops
or part suppliers.
[0120] The blockchains discussed herein may be updated after one or
more triggering events are detected. For instance, the triggering
events may include change of ownership, passage of time (e.g.,
every week, month, 3 months, or 6 months), amount of miles put on a
vehicle (e.g., 5,000 or 10,000 miles), an amount of time the
vehicle has driven, or operated if autonomous, vehicle or home
maintenance being performed or not being performed, change of
address, change in tax or insurance status, change in lender,
change in insurance carrier, etc.
EXEMPLARY ASPECTS
[0121] Embodiments of the techniques described in the present
disclosure may include any number of the following aspects, either
alone or combination. In one aspect, a computer-implemented method
for managing insurance records for policies for individuals may be
provided. The method may include configuring or implementing a
plurality of servers, each of the plurality of servers maintaining
a copy of a distributed ledger; performing the following when an
insurance policy is created for an individual: (i) generating, at a
first server from the plurality of servers, a transaction record
including data representing the created policy; (ii) proposing the
transaction record to one or more other servers from the plurality
of servers; (iii) performing, via the plurality of servers, a
consensus analysis of the transaction record utilizing a consensus
mechanism; and/or (iv) when the consensus analysis indicates that
the plurality of servers have formed a consensus, storing the
transaction record at the distributed ledger by storing the
transaction record to each copy of the distributed ledger at the
plurality of servers; and when a request for a verification of
insurance information is received, generating the verification by
retrieving from the distributed ledger all transaction records
pertaining to the individual, including the proposed transaction,
and generating a summary of all insurance policies represented by
the retrieved transaction records. The method may include
additional, less, or alternate functionality, including that
discussed elsewhere herein.
[0122] For instance, storing the transaction record at the
distributed ledger may include storing the transaction to a block.
Performing the consensus analysis may include generating a hash
value for the transaction, and utilizing the hash value for the
transaction to generate a hash value for the block. The consensus
mechanism may be: a proof of work mechanism, a proof of stake
mechanism, or a proof of activity mechanism. Additionally or
alternatively, the consensus mechanism may be: a proof of burn
mechanism, a proof of capacity mechanism, or a proof of elapsed
time mechanism.
[0123] The transaction record may include data representing: an
identity of the individual, a policy number for each insurance
policy held by the individual, and a coverage amount for each
insurance policy held by the individual. The method may include
verifying that a requestor that submitted the request for the
verification is authorized, wherein the verification is only
generated when requestor is authorized.
[0124] The method may include receiving from the individual a list
of authorized parties; wherein verifying that the requestor is
authorized includes verifying that the requestor is on the list of
authorized parties. The method may also include receiving from an
insurance company a list of authorized parties; wherein verifying
that the requestor is authorized includes verifying that the
requestor is on the list of authorized parties. The method may
include generating a notification that the individual has no
insurance records when the distributed ledger includes no
transaction records pertaining to the individual.
[0125] In another aspect, a computer system for managing insurance
records for a policies for individuals may be provided. The system
may include a plurality of servers maintaining a distributed ledger
for managing insurance records, wherein each of the plurality of
servers may include a memory storing: (A) a copy of the distributed
ledger, and (B) instructions that, when executed, cause the
respective server to: (i) generate, at the respective server, a
transaction record including data representing a created insurance
policy for an individual; wherein the plurality of servers are
configured to: (i) perform a consensus analysis of the proposed
transaction record utilizing a consensus mechanism; (ii) store the
transaction record at the distributed ledger when the consensus
analysis indicates that the plurality of servers have formed a
consensus by storing the transaction record to each copy of the
distributed ledger at the plurality of servers; and/or (iii)
generate a verification of insurance information for the individual
in response to receiving a request by retrieving from a copy of the
distributed ledger all transaction records, including the proposed
transaction record, and generating a summary of all insurance
policies represented by the retrieved transaction records. The
system may be include additional, less, or alternate functionality,
including that discussed elsewhere herein.
[0126] In another aspect, a computer-implemented method for
managing insurance records for an insured asset may be provided.
The method may include: configuring or implementing a plurality of
servers, each of the plurality of servers maintaining, or
configured to maintain, a copy of a distributed ledger; performing
the following when an insurance policy is created for an insured
asset: (i) generating, at a first server from the plurality of
servers, a transaction record including data representing the
created policy; (ii) proposing the transaction record to one or
more other servers from the plurality of servers; (iii) performing,
via the plurality of servers, a consensus analysis of the
transaction record utilizing a consensus mechanism; and/or (iv)
when the consensus analysis indicates that the plurality of servers
have formed a consensus, storing the transaction record at the
distributed ledger by storing the transaction record to each copy
of the distributed ledger at the plurality of servers; and when a
request for a verification of insurance information is received,
generating the verification by retrieving from the distributed
ledger all transaction records pertaining to the insured asset,
including the proposed transaction, and generating a summary of all
insurance policies represented by the retrieved transaction
records. Storing the transaction record at the distributed ledger
may include storing the transaction to a block, and the transaction
may pertain to a smart contract associated with the insured asset.
The transaction record may include data representing: information
describing the insured asset, an identity of the insured, a policy
number for each insurance policy held by the insured and/or
covering the insured asset, and a coverage amount for each
insurance policy. The method may include additional, less, or
alternate actions, including those discussed elsewhere herein.
[0127] For instance, the method may include verifying that a
requestor that submitted the request for the verification is
authorized, wherein the verification is only generated when the
requestor is authorized. The method may include receiving from the
individual a list of authorized parties; wherein verifying that the
requestor is authorized includes verifying that the requestor is on
the list of authorized parties. The method may include receiving
from an insurance company a list of authorized parties; wherein
verifying that the requestor is authorized includes verifying that
the requestor is on the list of authorized parties. The method may
include generating a notification that the insured asset has no
insurance records when the distributed ledger includes no
transaction records pertaining to the insured asset.
Additional Considerations
[0128] With the foregoing, an insurance customer may opt-in to a
rewards, insurance discount, or other type of program (such as the
UBI program described with reference to FIG. 7). After the
insurance customer provides their affirmative consent, an insurance
provider remote server may collect data from the customer's mobile
device, smart or autonomous vehicle, smart home controller, or
other smart devices. The data collected may be related to smart
home functionality (or home occupant preferences or preference
profiles), smart or autonomous vehicle functionality, and/or
insured assets before (and/or after) an insurance-related event,
including those events discussed elsewhere herein. In return, risk
averse insureds, home or vehicle owners, or home, vehicle, or
apartment occupants may receive discounts or insurance cost savings
related to home, renters, personal articles, auto, mobility, and
other types of insurance from the insurance provider.
[0129] In one aspect, telematics data, smart or autonomous vehicle
data, mobile device data, smart or interconnected home data, and/or
other data, including the types of data discussed elsewhere herein,
may be collected or received by an insurance provider remote server
(e.g., via direct or indirect wireless communication or data
transmission from a smart home controller, mobile device, or other
customer computing device) after a customer affirmatively consents
or otherwise opts-in to an insurance discount, reward, or other
program. The insurance provider may then analyze the data received
with the customer's permission to provide benefits to the customer.
As a result, risk averse customers may receive insurance discounts
or other insurance cost savings based upon data that reflects low
risk behavior and/or technology that mitigates or prevents risk to
(i) insured assets, such as homes, personal belongings, or
vehicles, and/or (ii) individuals.
[0130] 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.
[0131] 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. As
part of implementing the automotive claims process, vehicle loss
history, and the lifecycle of a Vehicle Identification Number, a
financial institution may be a part of the process. For example,
the aforementioned embodiments may be implemented by the 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.
[0132] With the foregoing, a user may be an insurance customer who
may opt-in to a rewards, insurance discount, or other type of
program. After the insurance customer provides their affirmative
consent, an insurance provider remote server may collect data from
the customer's mobile device, smart home controller, smart vehicle,
autonomous vehicle, or other smart devices--such as with the
customer's permission or affirmative consent. The data collected
may be related to smart vehicle or smart home functionality (or
home occupant preferences or preference profiles), and/or insured
assets before (and/or after) an insurance-related event, including
those events discussed elsewhere herein. In return, risk averse
insureds, home or vehicle owners, passengers or drivers may receive
discounts or insurance cost savings related to home, renters,
personal articles, auto, life, health, mobility, and other types of
insurance from the insurance provider.
[0133] 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.
[0134] 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.
[0135] 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.
[0136] 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.
[0137] 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.
[0138] 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).
[0139] 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.
[0140] 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.
[0141] 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.
[0142] 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.
[0143] 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.
[0144] 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.
[0145] 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).
[0146] 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.
[0147] 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).
* * * * *