U.S. patent application number 15/910352 was filed with the patent office on 2021-05-06 for using a distributed ledger for the auto claims process.
The applicant listed for this patent is STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY. Invention is credited to Jacob J. Alt, Eric Bellas, Shawn M. Call, Vicki King, William J. Leise, Melinda Teresa Magerkurth, Eric R. Moore, Jaime Skaggs.
Application Number | 20210133888 15/910352 |
Document ID | / |
Family ID | 1000003230137 |
Filed Date | 2021-05-06 |
![](/patent/app/20210133888/US20210133888A1-20210506\US20210133888A1-2021050)
United States Patent
Application |
20210133888 |
Kind Code |
A1 |
Leise; William J. ; et
al. |
May 6, 2021 |
Using a Distributed Ledger for the Auto Claims Process
Abstract
Systems and methods track a vehicle identifier or VIN on a
blockchain maintained by a plurality of participants. One method
may include (1) receiving, at a processor, a notification of a
vehicle loss report from a first participant; (2) storing, at a
memory coupled with the processor, the vehicle loss report on the
blockchain; (3) generating, at the processor, a coverage amount
based upon the vehicle loss report; (4) generating, at the
processor, an order based upon the notification, wherein the order
includes a repair assignment and a replacement vehicle request; (5)
storing, at the memory, the repair assignment on the blockchain;
(6) transmitting, at the processor, the order to at least a second
participant; (7) receiving, at the processor, a repair estimate
from the second participant; and/or (8) transmitting, at the
processor, the repair estimate and the coverage amount to the first
participant to facilitate maintaining a blockchain up-to-date.
Inventors: |
Leise; William J.; (Normal,
IL) ; Alt; Jacob J.; (Downs, IL) ; Skaggs;
Jaime; (Chenoa, IL) ; Bellas; Eric;
(Bloomington, IL) ; Call; Shawn M.; (Bloomington,
IL) ; Moore; Eric R.; (Heyworth, IL) ;
Magerkurth; Melinda Teresa; (Utica, IL) ; King;
Vicki; (Bloomington, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY |
Bloomington |
IL |
US |
|
|
Family ID: |
1000003230137 |
Appl. No.: |
15/910352 |
Filed: |
March 2, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62557433 |
Sep 12, 2017 |
|
|
|
62557415 |
Sep 12, 2017 |
|
|
|
62557403 |
Sep 12, 2017 |
|
|
|
62557393 |
Sep 12, 2017 |
|
|
|
62557359 |
Sep 12, 2017 |
|
|
|
62557446 |
Sep 12, 2017 |
|
|
|
62550131 |
Aug 25, 2017 |
|
|
|
62550224 |
Aug 25, 2017 |
|
|
|
62550245 |
Aug 25, 2017 |
|
|
|
62550140 |
Aug 25, 2017 |
|
|
|
62550172 |
Aug 25, 2017 |
|
|
|
62550186 |
Aug 25, 2017 |
|
|
|
62550261 |
Aug 25, 2017 |
|
|
|
62550197 |
Aug 25, 2017 |
|
|
|
62501621 |
May 4, 2017 |
|
|
|
62500977 |
May 3, 2017 |
|
|
|
62469070 |
Mar 9, 2017 |
|
|
|
62468092 |
Mar 7, 2017 |
|
|
|
62466917 |
Mar 3, 2017 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 30/0611 20130101;
G06Q 30/0645 20130101; G06F 16/27 20190101; G06Q 40/08 20130101;
G06Q 30/04 20130101 |
International
Class: |
G06Q 40/08 20060101
G06Q040/08; G06Q 30/06 20060101 G06Q030/06; G06F 17/30 20060101
G06F017/30; G06Q 30/04 20060101 G06Q030/04 |
Claims
1. A computer-implemented method for reporting and tracking events
related to an automotive claims process on a blockchain reported
and tracked by a plurality of participants in the blockchain
network, the method comprising: receiving, at a processor from a
first participant, a transaction including a vehicle loss report,
wherein the first participant is a sensor system of a vehicle
associated with the vehicle loss report having a cryptographic key
pair associated therewith, wherein the vehicle loss report includes
an indication of odometer data; verifying, at the processor, a
cryptographic key of the cryptographic key pair applied to the
transaction by the sensor system of the vehicle; storing, at a
memory coupled with the processor, the vehicle loss report on the
blockchain; accessing the memory coupled with the processor to
compare the odometer data with a usage-based insurance policy
associated with the vehicle; determining, at the processor, that
the odometer data is within a mileage limit associated with the
usage-based insurance policy; based upon the determination,
generating, at the processor, a coverage amount based upon the
vehicle loss report; generating, at the processor, an order based
upon the notification, wherein the order includes a repair
assignment and a replacement vehicle request; storing, at the
memory, the repair assignment on the blockchain; transmitting, at
the processor, the order to at least a second participant;
receiving, at the processor, a repair estimate from the second
participant; and transmitting, at the processor, the repair
estimate and the coverage amount to the first participant.
2. (canceled)
3. The computer-implemented method of claim 1, wherein the second
participant is a repair facility.
4. The computer-implemented method of claim 1 further comprising:
receiving, at the processor, a repair approval from a third
participant, wherein the third participant is the vehicle owner;
transmitting, at the processor, the repair approval to the second
participant; and storing, at the memory, the repair approval on the
blockchain.
5. The computer-implemented method of claim 1, further comprising:
transmitting, at the processor, the order to a fourth participant,
wherein the fourth participant is a rental provider; receiving, at
the processor, a rental bill from the fourth participant; and
storing, at the memory, the rental bill on the blockchain.
6. The computer-implemented method of claim 1, further comprising:
wherein prior to receiving the repair estimate, receiving, at the
processor, a parts delivery notification from a fifth participant,
wherein the fifth participant is a parts supplier; and storing, at
the memory, the parts delivery notification on the blockchain.
7. The computer-implemented method of claim 1, further comprising:
wherein prior to receiving the repair approval, receiving, at the
processor, a parts delivery confirmation from a sixth participant,
wherein the sixth participant is a logistics provider; and storing,
at the memory, the parts delivery confirmation on the
blockchain.
8. The computer-implemented method of claim 1, further comprising:
receiving, at the processor, a final repair bill from the second
participant; and storing, at the memory, the final repair bill on
the blockchain.
9. The computer-implemented method of claim 1, further includes:
wherein if items are stored on the blockchain, updating, at the
memory, a copy of the blockchain stored at the memory; and
transmitting, via the network interface, the updated copy of the
blockchain to at least one other participant.
10. The computer-implemented method of claim 1 receiving, at the
processor, a repair rejection from a third participant, wherein the
third participant is the vehicle owner; transmitting, at the
processor, the repair rejection to the second participant; and
storing, at the memory, the repair rejection on the blockchain.
11. A computer-implemented method for reporting and tracking events
related to an automotive claims process on a blockchain reported
and tracked by a plurality of participants in the blockchain
network, the method comprising: receiving, at a processor and from
a first participant, a transaction including a vehicle loss report
for a vehicle, wherein the first participant is a sensor system of
a vehicle associated with the vehicle loss report having a
cryptographic key pair associated therewith wherein the vehicle
loss report includes an indication of odometer data; verifying, at
the processor, a cryptographic key of the cryptographic key pair
applied to the transaction by the sensor system of the vehicle
accessing a blockchain record corresponding to the vehicle to
compare the odometer data with a usage-based insurance policy
associated with the vehicle; determining, at the processor, that
the odometer data is within a mileage limit associated with the
usage-based insurance policy; based upon the determination,
generating, at the processor, a coverage amount and an order based
upon the vehicle loss report; adding, at the processor, the
coverage amount and the order to the transaction; adding, at the
processor, the transaction to a block of transactions; generating,
at the processor, a cryptographic hash based upon the block of
transactions; adding, at the processor, the cryptographic hash in
the block of transactions; and transmitting, at the processor, the
block of transactions to a second participant.
12. The computer-implemented method of claim 11, wherein the second
participant is a repair facility.
13. The computer-implemented method of claim 11 further comprising:
receiving, at the processor, a repair approval from a third
participant, wherein the third participant is the vehicle owner;
transmitting, at the processor, the repair approval to the second
participant; and storing, at the blockchain record, the repair
approval on the blockchain.
14. The computer-implemented method of claim 11, further
comprising: receiving, at the processor, a second transaction from
at least one other participant in the blockchain network;
validating, at the processor, the second transaction by checking a
public-private key pair for the at least one other participant;
when the second transaction is valid, storing, at the blockchain
record, the second transaction to a copy of the blockchain, and
transmitting, at the processor, the second transaction to at least
one other participant in the blockchain network; and when the
second transaction is not valid, not storing the transaction, and
not transmitting the second transaction.
15. A system for reporting and tracking events related to an
automotive claims process on a blockchain reported and tracked by a
plurality of participants in the blockchain network, the system
comprising: a network interface configured to interface with a
processor; a memory configured to store non-transitory computer
executable instructions and configured to interface with the
processor; and the processor configured to interface with the
memory, wherein the processor is configured to execute the
non-transitory computer executable instructions to cause the
processor to: receive, from a first participant, a transaction
including a vehicle loss report, wherein the first participant is a
sensor system of a vehicle associated with the vehicle loss report
having a cryptographic key pair associated therewith, wherein the
vehicle loss report includes an indication of odometer data; verify
a cryptographic key of the cryptographic key pair applied to the
transaction by the sensor system of the vehicle; store the vehicle
loss report on the blockchain; generate a coverage amount based
upon the vehicle loss report; access a blockchain record
corresponding to the vehicle to compare the odometer data with a
usage-based insurance policy associated with the vehicle; determine
that the odometer data is within a mileage limit associated with
the usage-based insurance policy; based upon the determination,
generate an order based upon the vehicle loss report, wherein the
order includes a repair assignment and a replacement vehicle
request; store the repair assignment and the replacement vehicle
request on the blockchain; transmit the order to a second
participant; receive a repair estimate from the second participant;
and transmit the repair estimate and the coverage amount to the
first participant.
16. The system of claim 15, wherein the second participant is a
repair facility.
17. The system of claim 15, further comprising: receive a repair
approval from a third participant, wherein the third participant is
the vehicle owner; transmit the repair approval to the second
participant; and store the repair approval on the blockchain.
18. The system of claim 15, further comprising: transmit the order
to a fourth participant, wherein the fourth participant is a rental
provider; receive a rental bill from the fourth participant; and
store the rental bill on the blockchain.
19. The system of claim 15, further comprising: receive a repair
rejection from a third participant, wherein the third participant
is the vehicle owner; transmit the repair rejection to the second
participant; and store the repair rejection on the blockchain.
20. The system of claim 15, further comprising: receive a block of
transactions; validate the block of transactions; and store the
block of transactions on the blockchain.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to (1) U.S. Provisional
Application No. 62/466,917, entitled "Blockchain Vin Registry,"
filed Mar. 3, 2017; (2) U.S. Provisional Application No.
62/468,092, entitled "Blockchain Vin Registry," filed Mar. 7, 2017;
(3) U.S. Provisional Application No. 62/469,070, entitled "Using a
Blockchain for Vehicle Lifecycle Processes," filed Mar. 9, 2017;
(4) U.S. Provisional Application No. 62/500,977, entitled "Using a
Blockchain for Vehicle Lifecycle Processes," filed May 3, 2017; and
(5) U.S. Provisional Application No. 62/501,621, entitled "Using a
Blockchain for Vehicle Lifecycle Processes," filed May 4, 2017,
each of which is hereby incorporated herein by reference in its
entirety.
TECHNICAL FIELD
[0002] Systems and methods are disclosed with respect to using a
blockchain for vehicle lifecycle processes, specifically, an
automotive claims process, vehicle loss history, and the lifecycle
of a Vehicle Identification Number (VIN), or other identifier.
BACKGROUND
[0003] Vehicles undergo a variety of information exchange periods
during their lifecycle. Some of these information exchange periods
are brought on by accidents, sales, or the eventual destruction of
the vehicle. Managing the vehicle life cycle process may involve
multiple participants exchanging a variety of information. The
number of interactions between these parties may mean the parties
have to provide and validate information. Theses interactions may
often occur between businesses and consumers, or businesses and
other businesses. However, using conventional techniques, managing
the vehicle life cycle may include several drawbacks.
SUMMARY
[0004] In one aspect, a computer-implemented method for tracking a
vehicle identifier or VIN on a blockchain maintained by a plurality
of participants may be provided. The method may include (1)
receiving, at a processor, a notification of a vehicle loss report
(or other notification of a vehicle loss, such as a notification
that an insured vehicle has been damaged or involved in a vehicle
collision) from a first participant; (2) storing, at a memory
coupled with the processor, the vehicle loss report (or other
notification) on the blockchain; (3) generating, at the processor,
a coverage amount based upon the vehicle loss report (or other
notification); (4) generating, at the processor, an order based
upon the vehicle loss report or other notification, wherein the
order includes a repair assignment and a replacement vehicle
request; (5) storing, at the memory, the repair assignment on the
blockchain; (6) transmitting, at the processor, the order to at
least a second participant; (7) receiving, at the processor, a
repair estimate from the second participant; and/or (8)
transmitting, at the processor, the repair estimate and the
coverage amount to the first participant. The method may include
additional, less, or alternate actions, including those discussed
elsewhere herein.
[0005] In another aspect, a computer-implemented method for
reporting and tracking events related to an automotive claims
process on a blockchain reported and tracked by a plurality of
participants in the blockchain network may be provided. The method
may include (1) receiving, at a processor, a notification of a
vehicle loss report (or other notification of a vehicle loss, such
as a notification that an insured vehicle has been damaged or
involved in a vehicle collision) for a vehicle from a first
participant; (2) adding, at a memory coupled with the processor,
the vehicle loss report (or other notification) to a transaction;
(3) generating, at the processor, a coverage amount and an order
based upon the vehicle loss report (or other notification); (4)
adding, at the processor, the coverage amount and the order to the
transaction; (5) adding, at the processor, the transaction to a
block of transactions; (6) generating, at the processor, a
cryptographic hash based upon the block of transactions; (7)
adding, at the processor, the cryptographic hash in the block of
transactions; and/or (8) transmitting, at the processor, the block
of transactions to a second participant. The method may include
additional, less, or alternate actions, including those discussed
elsewhere herein.
[0006] In yet another aspect, a computer system for reporting and
tracking events related to an automotive claims process on a
blockchain reported and tracked by a plurality of participants in
the blockchain network may be provided. The system may include a
network interface configured to interface with a processor; a
memory configured to store non-transitory computer executable
instructions and configured to interface with the processor; and
the processor configured to interface with the memory. The
processor may be configured to execute the non-transitory computer
executable instructions to cause the processor to: (1) receive a
notification of a vehicle loss report (or other notification of a
vehicle loss, such as a notification that an insured vehicle has
been damaged or involved in a vehicle collision) from a first
participant; (2) store the vehicle loss report (or other
notification) on the blockchain; (3) generate a coverage amount
based upon the vehicle loss report (or other notification); (4)
generate an order based upon the vehicle loss report (or other
notification), wherein the order includes a repair assignment and a
replacement vehicle request; (5) store the repair assignment and
the replacement vehicle request on the blockchain; (6) transmit the
order to a second participant; (7) receive a repair estimate from
the second participant; and/or (8) transmit the repair estimate and
the coverage amount to the first participant. The method may
include additional, less, or alternate functionality, including
those discussed elsewhere herein.
[0007] The methods may be implemented via computer systems, and may
include additional, less, or alternate actions or functionality.
Systems or computer-readable media storing instructions for
implementing all or part of the method described above may also be
provided in some aspects. Systems for implementing such methods may
include one or more of the following: a special-purpose computing
device, a personal electronic device, a processing unit of a
vehicle, a remote server, one or more sensors, one or more
communication modules configured to communicate wirelessly via
radio links, radio frequency links, and/or wireless communication
channels, and/or one or more program memories coupled to one or
more processors of the personal electronic device, processing unit
of the vehicle, or remote server. Such program memories may store
instructions to cause the one or more processors to implement part
or all of the method described above. Additional or alternative
features described herein below may be included in some
aspects.
[0008] 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
[0009] 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.
[0010] 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:
[0011] FIG. 1A depicts an exemplary database system 100 in
accordance with one aspect of the present disclosure;
[0012] FIG. 1B depicts an exemplary distributed ledger system 112
in accordance with one aspect of the present disclosure;
[0013] FIG. 2A depicts an exemplary transaction flow 200 in
accordance with one aspect of the present disclosure;
[0014] FIG. 2B depicts an exemplary block propagation flow 210 in
accordance with one aspect of the present disclosure;
[0015] FIG. 3 depicts an exemplary sequence diagram 300 in
accordance with one aspect of the present disclosure;
[0016] FIG. 4 depicts an exemplary node 400 in accordance with one
aspect of the present disclosure;
[0017] FIG. 5 depicts an exemplary blockchain 500 in accordance
with one aspect of the present disclosure;
[0018] FIG. 6 depicts an exemplary flow diagram 600 associated with
one aspect of the present disclosure;
[0019] FIG. 7 depicts an exemplary flow diagram 700 associated with
one aspect of the present disclosure;
[0020] FIG. 8 depicts an exemplary flow diagram 800 associated with
one aspect of the present disclosure;
[0021] FIG. 9 depicts an exemplary flow diagram 800 associated with
one aspect of the present disclosure.
[0022] FIG. 10 depicts exemplary VIN based vehicle services that
may be facilitated via the Blockchain VIN Registry.
[0023] FIG. 11 depicts exemplary transactions that may be recorded,
logged, or updated in each block of a distributed ledger or
Blockchain VIN Registry 1100; and
[0024] FIG. 12 depicts an exemplary flow diagram 1200 associated
with one aspect of the present disclosure.
[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 blockchain to record information related to
processes and services in the automotive industry. For example, a
blockchain may be used to manage the automotive claims process, a
vehicle's loss history, and the lifecycle of a Vehicle
Identification Number. The systems and methods described herein
allow for using a blockchain which gives the option for private
information, and permissioned participants in the blockchain. In
particular, the systems and methods allow for a distributed
consensus amongst businesses, consumers, and authorities, as to the
validity of information and transactions stored on the
blockchain.
[0027] Some exemplary, but not limiting, applications that may take
advantage of the disclosed systems and methods relate to problems
surrounding the automotive claims process, vehicle loss history,
and the lifecycle of a Vehicle Identification Number. Specifically,
such applications may be: processing automotive insurance claims,
tracking a vehicle's loss history, tracking a Vehicle
Identification Number over the course of the vehicle's life,
transferring a vehicle title in a total loss scenario, subrogation
transactions related to a vehicle accident, transferring a vehicle
title, executing and processing travel insurance, interacting with
original equipment manufacturers for a vehicle, and tracking
information from the national insurance crime bureau.
[0028] The present embodiments may be related to a Blockchain VIN
Registry. A national or other registry of automobile VIN numbers
may be commonly accessed and/or updated by organizations, such as
auto manufacturers, insurance carriers, financial institutions,
fleet owners, banks, body shops, part suppliers, State Departments
of Motor Vehicles (DMVs), and/or salvage vendors. The VIN Registry,
utilizing blockchain technology, may be a single, historical,
authoritative source for multiple pieces of information about each
vehicle that is accessed, tracked, and updated using Vehicle
Identification Numbers (VINs).
[0029] The Blockchain VIN Registry may have various usages, and may
allow for the introduction of new capabilities into current
processes. Examples of such usage include: (1) validating proof of
insurance on a vehicle (available to law enforcement, lienholders,
vehicle owners, etc.); (2) tracking vehicle ownership from "cradle
to grave," via seamless title transfers between manufacturers,
dealers, consumers, salvage yard, etc.; (3) identifying the current
lienholder of a vehicle, and the current lien payoff amount (e.g.,
for more frictionless processing of payment such as in a total loss
situation, or for loan refinancing situations); (4) ensuring lien
perfection (e.g., title reflects joint ownership by person and
lienholder); (5) reducing fraud by detecting duplicate coverage or
duplicate claims for a single vehicle, or detecting buildup or
questionable claims; (6) tracking maintenance or repair work that
has been, or is to be, performed on a vehicle; (7) when coupled
with crash detection, performing first notification of loss to the
appropriate insurer; (8) in conjunction with connected car
capabilities, limiting the vehicle's capabilities if the vehicle
isn't registered properly, lacks insurance coverage, or the owner
is behind on loan payments; (9) connected license plates,
reflecting the current registration status; (10) facilitating
Usage-Based Insurance (UBI) or trip-based insurance; (11) recording
all OEM features, part numbers, (autonomous or other vehicle)
system or software of versions of the vehicle (beyond what can be
derived from the VIN, make, and model information), i.e., the
vehicle build; (12) more accurate insurance rating based upon known
security or safety features of a vehicle (which may impact either a
human driven vehicle, or a semi-autonomous or autonomous vehicle or
technology, or both); (13) more accurate repair cost estimations
based upon known vehicle features (which may impact human driving,
or vehicle self-driving); and/or (14) facilitating recall
notifications in a prompt and reliable manner.
[0030] Potential blockchain participants may include auto
manufacturers, insurance carriers, consumers, individual vehicle
owners, fleet owners, salvage vendors, auditors, State DMVs, auto
dealerships, banks or credit unions, lienholders, body shops,
repair facilities, tow truck operations, part supplies, rental
companies, and/or law enforcement.
[0031] Potential data elements included in the blockchain and/or
each blockchain transaction, block, or update may include vehicle
VIN number, and one or more additional data elements associated
with that particular vehicle. The additional data elements may
include owner information, such as owner type (manufacturer,
dealer, consumer, lienholder, etc.); owner ID (EIN, SSN, etc.);
owner name; and/or owner contact information (address, phone, email
address, etc.). The additional data elements may include insurance
carrier information, such as insurer name; insurance policy ID or
number; an indication of whether the policy remains in force
(Y/N?); effective dates of the policy; expiration date of the
insurance coverage; and/or insurance policy coverages, terms,
limits, deductibles, conditions, etc.
[0032] The additional data elements may include lienholder
information, such as lienholder name; lienholder contact
information; whether the loan is in good standing (Y/N?); and/or
current payoff amount. The additional data elements may include a
license plate number; state of issuance; and whether the vehicle
registration with the state DMV is up-to-date. The additional data
elements may include an indication of any claims made; including
date of first notice of loss; insurance carrier that the claim was
filed with; claim open date; claim close date; an amount of the
claim; and whether or not the claim was resolved. The additional
data elements may include information on maintenance or repair
events, including event type; event date; event cost; and/or one or
more locations associated with the event (e.g., city and state of
event location).
[0033] The Blockchain VIN Registry may be used in conjunction with
smart contracts that govern the vehicles, including autonomous or
semi-autonomous vehicles. For instance, the smart contracts may
related to maintenance, warranties, vehicle loans, service
contracts, UBI, trip-insurance, auto insurance policies, vehicle
titles, vehicle salvage, total loss vehicles, etc. When an event or
data relevant to a vehicle or a smart contract is generated, a
transaction associated with the vehicle's VIN may be generated and
compiled into a block of a distributed ledger (or Blockchain VIN
Registry). The transaction or update to the distributed ledger or
Blockchain VIN Registry may include (i) the vehicle's VIN, and (ii)
one or more additional data elements associated with the vehicle,
including the additional data elements mentioned elsewhere
herein.
[0034] 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."
[0035] 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 a transactional record is maintained at each node
of a peer to peer network. Commonly, the distributed ledger is
comprised of groupings of transactions bundled together into a
"block." When a change to the distributed ledger is made (e.g.,
when a new transaction and/or block is created), each node must
form a consensus as to how the change is integrated into the
distributed ledger. Upon consensus, the agreed upon change is
pushed out to each node so that each node maintains an identical
copy of the updated distributed ledger. Any change that does not
achieve a consensus is ignored. Accordingly, unlike a traditional
system which 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.
[0036] 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.
[0037] 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.
[0038] According to certain aspects disclosed herein, information
stored in blockchains can be trusted, because the hash value
generated for the new block and a nonce value (an arbitrary number
used once) are used as inputs into a cryptographic puzzle. The
cryptographic puzzle may have a difficulty set by the nodes
connected to the blockchain network, or the difficulty may be set
by administrators of the blockchain network. In one example of the
cryptographic puzzle, a solving node uses the hash value generated
for the new block and repeatedly changes the value of the nonce
until a solution for the puzzle is found. For example, finding the
solution to the cryptographic puzzle may involve finding the nonce
value that meets certain criteria (e.g., the nonce value begins
with five zeros).
[0039] 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.
[0040] Blockchains may store smart contracts. A smart contract is a
computer protocol that enables the automatic execution and/or
enforcement of an agreement between different parties. In
particular, the smart contract may be computer code that is located
at a particular address on the blockchain. In some cases the smart
contract may run automatically in response to a participant in the
blockchain sending funds (e.g., a cryptocurrency such as bitcoin or
ether) to the address where the smart contract is stored.
Additionally, smart contracts may maintain a balance of the amount
of funds that are stored at their address. In some scenarios, when
this balance reaches zero, the smart contract may no longer be
operational.
[0041] The smart contract may include one or more trigger
conditions, that, when satisfied, correspond to one or more
actions. For some smart contracts, which action(s) from the one or
more actions are performed is determined based upon one or more
decision conditions. An enforcement entity corresponding to the
smart contract may subscribe to one or more data streams including
data related to a trigger condition and/or a decision condition.
Accordingly, the enforcement entity may route the data streams to
the smart contract (such as by using the vehicle's VIN) so that the
smart contract may detect that a trigger condition has occurred
and/or analyze a decision condition to direct the enforcement
entity to perform one or more actions.
[0042] As noted herein, after collection of the information
regarding the vehicle by one or more nodes within a communication
network, a transaction (and/or new block) including the vehicle
information collected may be broadcast to the blockchain, and/or a
new block verified and then added to the blockchain to reflect an
updated state of the vehicle. For each of the computer-implemented
methods discussed herein, in one embodiment, a transaction and/or
new block may be generated and then broadcast to the blockchain
network for verification once vehicle data, and/or new sensor or
other data, have been generated and/or collected by one or more
nodes within the communication network. As such, tracking the
status of a vehicle may be more reliable and/or fraud-resistant as
each node may include a proof-of-identity in its transaction
modifying the state of the vehicle and/or vehicle-related blocks or
blockchain.
[0043] Further, with the computer-implemented methods discussed
herein, network participants may function as full nodes that
validate and/or generate new blocks and transactions, and/or
compile transactions into blocks that are then added to the
network. However, not all participants need be nodes that compile
transactions into blocks, and/or validate transactions and blocks
received from other network participants--as some network
participants may wish to rely on other network nodes to provide
computer processing and/or storage services that enable usage of
the system or blockchain.
Exemplary Database & Distributed Ledger
[0044] FIG. 1A depicts an exemplary database system 100 in
accordance with one aspect of the present disclosure. FIG. 1A
includes a central authority 102, a plurality of nodes 104A, 104B,
and 106, a central ledger 108, and a plurality of network
connections 110. In one exemplary operation of the database system
100, one of the nodes, for example Node A 104A, would issue a
request to the central authority 102 to perform an action on data
stored in the central ledger 108. This request may be a request to
create, read, update, or delete data that is stored in the central
ledger 108.
[0045] The central authority 102 would receive the request,
processes the request, make any necessary changes to the data
stored in the central ledger 108, and inform the requesting node,
Node A 104A, of the status of the request. The central authority
102 may also send out status updates to the other nodes on the
network about the change made, if any, to the data by Node A 104A.
In the database system 100, all interaction with the data stored in
the central ledger 108 occurs through the central authority 102. In
this way, the central authority functions as a gatekeeper of the
data.
[0046] Accordingly, the central authority 102 may operate as a
single point of entry for interacting with the data, and
consequently the central authority 102 is a single point of failure
for the entire database system 100. As such, if the central
authority 102 is not accessible to the nodes in the database system
100, then the data stored in the central ledger 108 is not
accessible. In another example, each individual node may keep their
own databases and then at the end of the day each node sends a copy
of their database to the central authority 102 where the received
databases are reconciled to form a single cohesive record of the
data stored in the central ledger 108.
[0047] Conversely, FIG. 1B depicts an exemplary distributed ledger
system 112 in accordance with one aspect of the present disclosure.
An example of a distributed ledger system 112 is the blockchain
system described above. FIG. 1B includes a plurality of nodes 104A,
104B, and 106, a distributed ledger 114, and network connections
110. In a distributed ledger system 112, each node keeps a copy of
the distributed ledger 114. As changes are made to the distributed
ledger 114 each node updates their copy of the distributed ledger
114. A consensus mechanism may be used by the nodes in the
distributed ledger system 112 to decide when it is appropriate to
make changes to the distributed ledger 114.
[0048] Therefore, each node has their own copy of the distributed
ledger 114, which is identical to every other copy of the
distributed ledger 114 stored by each other node. The distributed
ledger system 112 is more robust than a central authority database
system, because the distributed ledger system 112 is decentralized
and there is no single point of failure.
Exemplary Transaction Flow & Block Propagation Flow
[0049] FIG. 2A depicts an exemplary transaction flow 200 in
accordance with one aspect of the present disclosure. FIG. 2A
includes a transaction 202, three different time frames 204, 206,
and 208, a set of nodes, network connections 110, and a distributed
ledger 114. The transaction flow 200 may represent a sequential
flow of a transaction through a network, such as the network
depicted in FIG. 1B. For example, at time 204 Node A 104A generates
a transaction 202 or event.
[0050] The transaction 202 may use data that is stored in the
distributed ledger 114, or the transaction 202 may use data
received by the node from outside the distributed ledger 114. Node
A 104A may transmit the newly generated transaction to Node C 106
via the network connection 110. At time 206, Node C 106 receives
the transaction 202, and confirms that the information contained
therein is correct. If the information contained in the transaction
202 is not correct Node C 106 may reject the transaction, and not
propagate the transaction 202 through the system. If the
information contained in the transaction 202 is correct Node C 106
may transmit the transaction 202 to its neighbor Node B 104B.
[0051] Similarly, at time 208 Node B 104B may receive the
transaction 202 and either confirm or reject the transaction 202.
In some embodiments, the Node B 104B may not transmit the confirmed
transaction 202, because there are no further nodes to transmit to,
or all the nodes in the network have already received transaction
202.
[0052] In some embodiments, at any of time frames 204, 206, or 208,
any of the nodes may add the confirmed transaction 202 to their
copy of the distributed ledger 114, or to a block of transactions
stored in the distributed ledger. In some embodiments, confirming
the transaction 202 includes checking 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.
[0053] 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, Node C 106 and Node B 104B, a
set of transactions 202A-202D, a set of blocks of transactions
216A-216D, a distributed ledger 114, and a blockchain 218. The
block propagation flow 210 may follow the blockchain system
described above, or may follow another blockchain propagation
algorithm.
[0054] The block propagation flow 210 may begin with Node C 106
receiving transaction 202A at time 212. When Node C 106C confirms
that transaction 202A is valid, the node may add the transaction to
a newly generated block 216. As part of adding the transaction 202A
to block 216, Node C 106 may solve a cryptographic puzzle and
include the solution in the newly generated block 216 as proof of
the work done to generate the block 216. This proof of work may be
similar to the proof of work described above which utilizes
guessing a nonce value. In other embodiments, the transaction 202A
may be added to a pool of transactions until enough transactions
exist to form a block. Node C 106 may transmit the newly created
block 216 to the network at 220. Before or after propagating the
block 216, Node C 106 may add the block 216 to its copy of the
blockchain 218.
[0055] At time 214 Node B 104B may receive the newly created block
216. Node B 104B may verify that the block of transactions 216 is
valid by checking the solution to the cryptographic puzzle provided
in the block 216. If the solution is accurate then Node B 104B may
add the block 216 to its blockchain 218 and transmit the block 216
to the rest of the network at 222.
[0056] In one embodiment, one or more transactions 202 or events
may relate to smart contracts associated with the vehicle or a VIN
(Vehicle Identification Number), or vehicle owner or driver. The
smart contracts may relate to vehicle financing, vehicle ownership,
vehicle title and registration, vehicle maintenance or repair, and
other vehicle-related events or transactions.
[0057] For example, a smart contract may be stored on the
blockchain 218. The smart contract may include terms of a contract
for vehicle financing, the payor and payee of the contract, actions
to be performed related to the contract, and any other related
items to the contract. The smart contract may be found on the
blockchain 218 via the vehicle identifier. As transactions 202 are
received information contained in the transaction may indicate that
a payment for the vehicle financing has been made, and accordingly
the smart contract may be updated to reflect this payment, and
potentially trigger other actions to occur, such as notifying the
lender. These actions, and terms, are stored in the smart contract
on the blockchain 218, and may be visible to the parties to the
vehicle financing, to all the participants in the blockchain 218,
or to only some participants in the blockchain 218.
Exemplary Sequence Diagram
[0058] FIG. 3 depicts an exemplary sequence diagram 300 in
accordance with one aspect of the present disclosure. FIG. 3
includes a set of nodes 104A, 104B, and 106. At 302, Node A 104A
may generate a transaction. The transaction may be transmitted from
Node A 104A to Node C 106 at 304. Node C 106 may validate the
transaction at 306, and if the transaction is valid, transmit the
transaction at 308 to Node B 104B. Node B 104B may validate the
transaction at 310. At 312, Node C 106 may compile a block
including the validated transaction. Compiling a block may include
generating a solution to a cryptographic puzzle, and linking the
block to other blocks, as described in the embodiments above. Once
the block is compiled, Node C 106 may transmit the block with the
solution at 314 to both Node A 104A and Node B 104B.
[0059] Both nodes may then validate the solution to the block at
316. Verifying may include checking a cryptographic key-pair as
described above. At 318 the three nodes form a consensus that the
solution is valid, and accordingly all the nodes have formed a
consensus on the blocks of transactions stored by all the
nodes.
Exemplary Node
[0060] FIG. 4 depicts an exemplary node 400 in accordance with one
aspect of the present disclosure. In some embodiments, node 400 may
be the same type of node as Node C 106 in FIGS. 1A-3. In other
embodiments, node 400 may be the same type of node as Node A 104A
and Node B 104B in FIGS. 1A-3. Node 400 may be capable of
performing all the embodiments disclosed herein. In particular,
node 400 may utilize the decentralized system described in FIG. 1B,
the flows of transactions and blocks described in FIGS. 2A and 2B,
and the blockchain system 500 described below in FIG. 5.
[0061] FIG. 4 may include at least one processor 402, memory 404, a
communication module 406, a set of applications 408, external ports
410, user interface 412, a blockchain manager 414, smart contracts
416, operating system 418, a display screen 420, and input/output
components 422. In some embodiments, the node 400 may generate a
new block of transactions by using the blockchain manager 414.
Similarly, the node 400 may use the blockchain manager 414 in
conjunction with the smart contracts 416 stored in memory 404 to
execute the functionality disclosed herein. In general, the smart
contracts 416 include code that is shared with all, or some, of the
participants in the blockchain network in which the node 400
participates. This code may be used to ensure transparency in
transactions, agreements, and other events that are recorded on the
blockchain.
[0062] In other embodiments, the smart contracts 416 operate
independent of the blockchain manager 414 or other applications. In
some embodiments, node 400 does not have a blockchain manager 414,
or smart contracts 416 stored at the node. In some embodiments, the
node 400 may have additional or less components than what is
described. The components of the node 400 are described in more
detail below.
[0063] The node 400, as part of a decentralized ledger system 112,
or another decentralized or centralized network, may be used to
handle systems that interact with and manipulate data and
transactions designed for the automotive claims process, a vehicle
loss history, and the lifecycle of a Vehicle Identification
Number.
Exemplary Blockchain System
[0064] FIG. 5 depicts an exemplary blockchain system 500 in
accordance with one aspect of the present disclosure. FIG. 5
includes a blockchain 502, a block of transactions 504, a Merkle
Tree 506, and a transaction 508. The Merkle Tree may be the same
Merkle Tree referred to above that cryptographically links
transactions together. In other embodiments, the blockchain system
500 may utilize a different method of organizing transactions in a
block. In some embodiments, the blockchain system 500 includes a
plurality of blocks connected together to form a chain of blocks of
transactions 502.
[0065] Each block of transactions 504 may include at least one
transaction 508. In other embodiments, each block of transactions
504 has a size limit that necessarily limits the number of
transactions that the block may store. Each block of transactions
504 includes a reference to a previous block of transactions that
was added to the blockchain 502 prior to the block of transactions
504 being added to the blockchain 502. As such, and as described
above, each block of transactions 504 is linked to every other
block in the blockchain 502.
[0066] In some embodiments, the block of transactions 504 may
organize the transactions it has received into a Merkle Tree 506 to
facilitate access to the stored transactions. The transactions may
be hashed using a cryptographic hash algorithm, such as the
algorithms discussed above, and the hash of each transaction is
stored in the tree. As the tree is constructed the hash of each
adjacent node 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 identifying data for the transaction, and transaction
data identifying the nature of the transaction and what the
transactions entails.
Reporting and Tracking the Auto Claim Process
[0067] In one embodiment, reporting and tracking events related to
an automotive claims process is conducted on a blockchain. The
automotive insurance claims process may involve the following
parties: a vehicle owner, an insurer, a repair facility, a parts
supplier, a logistics provider, and a rental provider. Presently,
the process may involve a considerable amount of communication, and
coordination back and forth between all of the relevant parties
listed above. As such, the process can be time consuming, and there
are difficulties ensuring the correct information is received by
the correct party at the correct time. By instituting the process
on a blockchain significant time and resource improvements can be
obtained.
[0068] After a vehicle owner is in an accident, the claims process
may begin when the insurer receives a loss report or loss
notification for the vehicle. The insurer determines coverage based
upon the loss report, triages the vehicle, and sends a repair
assignment to a repair facility. Optionally, the insurer may assign
a rental vehicle to the vehicle owner if applicable. The rental
provider provides the rental vehicle accordingly. Throughout the
process, the vehicle owner may provide authorization to repair the
vehicle, and pay for such repairs, and pays a deductible.
[0069] At some point a repair facility takes control of the
vehicle. In some cases the repair facility may provide a rental
car, or substitute transportation to the vehicle owner. The repair
facility may secure authorization to repair the vehicle from the
vehicle owner. Once this is secured, the repair facility identifies
potential areas of prior damage/betterment, develops a repair plan,
and prepares a repair estimate. The repair facility may request
parts from suppliers, finalize any parts orders, update the
estimate accordingly, and generally manage the repair of the
vehicle. For the present embodiments, as part of the repair
process, the repair facility may provide photographic evidence of
the damage done to the vehicle. These photographs may then be
uploaded to the blockchain after they have been hashed so as to
ensure that any private information is protected, but also that the
photographs provided are valid.
[0070] The insurer is largely responsible for determining the
coverage, coordinating with the repair facility and rental
provider, and for communicating with the vehicle owner.
Additionally, in some embodiments, the insurer may be a provider of
the network on which the blockchain to manage the process is
stored, or may be a participant on the network.
[0071] All of the participants in the network may be responsible
for verifying information that is stored on the blockchain, and
providing additional information to the blockchain to facilitate
the auto claims process. Some of the participants may function as
nodes that compile transactions into blocks that are then added to
the network, but not all participants need be nodes that compile
transactions into blocks.
[0072] In one exemplary embodiment, the systems and methods
disclosed may be used by a participant to receive a vehicle loss
report, access a block stored on a blockchain to determine if
information for the vehicle corresponding to the vehicle loss
report (or notification) is stored on the blockchain, analyze the
received vehicle identifier notification, perform any necessary
changes to information stored on the blockchain related to the
vehicle and/or the vehicle loss report, and transmit the block
where the vehicle information is stored, or a vehicle loss report
is stored, to another participant on the network. In some cases,
updating and transmitting the block includes creating a new block
with relevant information that will be added to the blockchain. In
some embodiments, a node, such as the node 400 depicted in FIG. 4,
may be the recipient of the vehicle loss report, and the node may
be a part of a distributed ledger system, such as the system 112 of
FIG. 1B. In some embodiments, a graphical user interface may be
used to ensure that a user, or participant, may interact with the
data presented, and more easily track the relevant data as it
progresses through its process and is stored on the blockchain.
Additionally, as part of the process any relevant title
information, or any liens that are held against the vehicle, may be
a part of the process.
Exemplary Computer Implemented Method for Reporting and Tracking
the Auto Claim Process
[0073] FIG. 6 depicts an exemplary flow diagram 600 associated with
one aspect of the present disclosure, in particular, using a
blockchain for reporting and tracking events related to an
automotive claims process among a network of participants. In some
embodiments, the network of participants may be the nodes described
above, for example, node 400 depicted in FIG. 4. The blockchain
used by the participants may be the blockchain 500 depicted in FIG.
5, whose operation is described in FIGS. 2A, 2B, and 5. The steps
of the computer-implemented method 600 may be performed by the
nodes in the network of participants, such as the nodes described
in FIGS. 1A-4. The method 600 may include additional, fewer, or
alternative actions, including those described elsewhere
herein.
[0074] The method 600 for reporting and tracking events related to
an automotive claims process on a blockchain reported and tracked
by a plurality of participants in the blockchain network may
include (1) receiving, at a processor, a notification of a vehicle
loss or a vehicle loss report (or other notification of a vehicle
loss, such as a notification that an insured vehicle has been
damaged or involved in a vehicle collision) from a first
participant (block 602); (2) storing, at a memory coupled with the
processor, the vehicle loss report on the blockchain (block 604);
(3) generating, at the processor, a coverage amount based upon the
vehicle loss report (block 606); (4) generating, at the processor,
an order based upon the notification, wherein the order includes a
repair assignment and a replacement vehicle request (block 608);
(5) storing, at the memory, the repair assignment on the blockchain
(610); (6) transmitting, at the processor, the order to at least a
second participant (block 612); (7) receiving, at the processor, a
repair estimate from the second participant (block 614); and/or (8)
transmitting, at the processor, the repair estimate and the
coverage amount to the first participant (block 616).
[0075] In some embodiments, the first participant is the vehicle
owner, and in other embodiments the second participant is a repair
facility. In other embodiments, both the first participant is the
vehicle owner and the second participant is a repair facility.
[0076] In some embodiments, the method may further include
receiving, at the processor, a repair approval from the first
participant; transmitting, at the processor, the repair approval to
the second participant; and/or storing, at the memory, the repair
approval on the blockchain. Alternatively, the computer implemented
method may further include transmitting, at the processor, the
order to a third participant, wherein the third participant is a
rental provider; receiving, at the processor, a rental bill from
the third participant; and storing, at the memory, the rental bill
on the blockchain.
[0077] In yet other embodiments, prior to receiving the repair
estimate, the method may include receiving, at the processor, a
parts delivery notification from a fourth participant, wherein the
fourth participant is a parts supplier; and/or storing, at the
memory, the parts delivery notification on the blockchain.
Similarly, in some embodiments, prior to receiving the repair
approval, receiving, at the processor, a parts delivery
confirmation from a fifth participant, wherein the fifth
participant is a logistics provider; and/or storing, at the memory,
the parts delivery confirmation on the blockchain.
[0078] In some embodiments, the method may include receiving, at
the processor, a final repair bill from the second participant;
and/or storing, at the memory, the final repair bill on the
blockchain. Additionally, in some embodiments the method may
include, wherein if items are stored on the blockchain, updating,
at the memory, a copy of the blockchain stored at the memory;
and/or transmitting, via the network interface, the updated copy of
the blockchain to at least one other participant. Similarly, some
embodiments include receiving, at the processor, a repair rejection
from the first participant; transmitting, at the processor, the
repair rejection to the second participant; and/or storing, at the
memory, the repair rejection on the blockchain.
[0079] In some embodiments, the vehicle loss report (or a
notification of a vehicle loss, or notification that an insured
vehicle has been damaged or involved in a vehicle collision) may be
used to access the blockchain and identify a smart contract
associated with the vehicle. The vehicle loss report (or
notification) may be used to update the smart contract using
information included in the vehicle loss report (or
notification).
[0080] In an alternative embodiment, a computer-implemented method
for reporting and tracking events related to an automotive claims
process on a blockchain reported and tracked by a plurality of
participants in the blockchain network may be provided. The method
may include (1) receiving, at a processor, a notification of a
vehicle loss report (or other notification of a vehicle loss, such
as a notification that an insured vehicle has been damaged or
involved in a vehicle collision) for a vehicle from a first
participant; (2) adding, at a memory coupled with the processor,
the vehicle loss report to a transaction; (3) generating, at the
processor, a coverage amount and an order based upon the vehicle
loss report; (4) adding, at the processor, the coverage amount and
the order to the transaction; (5) adding, at the processor, the
transaction to a block of transactions; (6) generating, at the
processor, a cryptographic hash based upon the block of
transactions; (7) adding, at the processor, the cryptographic hash
in the block of transactions; and/or (8) transmitting, at the
processor, the block of transactions to a second participant.
[0081] In some embodiments, the first participant is the vehicle
owner, and the second participant is a repair facility. In other
embodiments, the method may include receiving, at the processor, a
repair approval from the first participant; transmitting, at the
processor, the repair approval to the second participant; and/or
storing, at the memory, the repair approval on the blockchain.
[0082] In some embodiments, the method may include receiving, at
the processor, a transaction from at least one other participant in
the blockchain network; validating, at the processor, the
transaction by checking a public-private key pair for the at least
one other participant; when the transaction is valid, storing, at
the memory, the transaction to a copy of the blockchain, and
transmitting, at the processor, the transaction to at least one
other participant in the blockchain network; and/or when the
transaction is not valid, not storing the transaction, and not
transmitting the transaction.
[0083] In yet another embodiment, a computer system for reporting
and tracking events related to an automotive claims process on a
blockchain reported and tracked by a plurality of participants in
the blockchain network may be provided. The system may include a
network interface configured to interface with a processor; a
memory configured to store non-transitory computer executable
instructions and configured to interface with the processor; and
the processor configured to interface with the memory. The
processor may be configured to execute the non-transitory computer
executable instructions to cause the processor to: (1) receive a
notification of a vehicle loss report (or other notification of a
vehicle loss, such as a notification that an insured vehicle has
been damaged or involved in a vehicle collision) from a first
participant; (2) store the vehicle loss report (or other
notification) on the blockchain; (3) generate a coverage amount
based upon the vehicle loss report (or other notification); (4)
generate an order based upon the vehicle loss report (or other
notification), wherein the order includes a repair assignment and a
replacement vehicle request; (5) store the repair assignment and
the replacement vehicle request on the blockchain; (6) transmit the
order to a second participant; (7) receive a repair estimate from
the second participant; and/or (8) transmit the repair estimate and
the coverage amount to the first participant. The system may
include additional, less, or alternate functionality, including
that discussed elsewhere herein.
Vehicle Loss History
[0084] In one embodiment, reporting and tracking events related to
a vehicle loss history, are stored on a blockchain maintained by a
plurality of participants. The vehicle loss history may include
information on the following parties: a vehicle owner, an insurer,
a repair facility, a parts supplier, a logistics provider, and a
rental provider. Presently, the process involves a considerable
amount of communication, and coordination back and forth between
potentially all of the relevant parties listed above. As such, the
process may be time consuming, and there may be difficulties
ensuring the correct information is received by the correct party
at the correct time. By instituting the process for tracking and
reporting on a blockchain significant time and resource
improvements can be obtained.
[0085] In one exemplary embodiment, the systems and methods
disclosed may be used by a participant to receive a loss history
for a vehicle, access a block stored on a blockchain to determine
if information for the vehicle is stored on the blockchain, analyze
the received vehicle loss history, perform any necessary changes to
information stored on the blockchain related to the vehicle and/or
the vehicle loss history, and transmit the block where the vehicle
information is stored, or vehicle loss history is stored, to
another participant on the network. In some cases, updating and
transmitting the block includes creating a new block with relevant
information that will be added to the blockchain. In some
embodiments, a node, such as the node 400 depicted in FIG. 4, may
be the recipient of the vehicle loss history, and the node may be a
part of a distributed ledger system, such as the system 112 of FIG.
1B. In some embodiments, a graphical user interface may be used to
ensure that a user, or participant, may interact with the data
presented and more easily track as the relevant data progresses
through its process and is stored on the blockchain. Additionally,
as part of the process any relevant title information or any liens
that are held against the vehicle may be part of the process.
Exemplary Computer Implemented Method for Vehicle Loss History
[0086] FIG. 7 depicts an exemplary flow diagram 700 associated with
one aspect of the present disclosure for tracking a vehicle loss
history, stored on a blockchain maintained by a plurality of
participants. In some embodiments, the network of participants may
be the nodes described above, for example node 400 depicted in FIG.
4. The blockchain used by the participants may be the blockchain
500 depicted in FIG. 5, whose operation is described in FIGS. 2A,
2B, and 5. The steps of the computer-implemented method 700 may be
performed by the nodes in the network of participants, such as the
nodes described in FIGS. 1A-4. The method 700 may include
additional, fewer, or alternative actions, including those
described elsewhere herein.
[0087] The exemplary flow diagram 700 may include (1) receiving, at
a processor coupled with a network interface, a vehicle loss
notification from at least a first participant, wherein the vehicle
loss notification includes a vehicle identifier, a driver
identifier, and a vehicle loss report (block 702); (2) accessing,
at a memory coupled with a processor, the blockchain using the
vehicle identifier (block 704); (3) updating, at the memory, a
block stored at the memory using the vehicle identifier, the driver
identifier, and the vehicle loss report (block 706); and/or (4)
transmitting, via the processor coupled with the network interface,
the block to at least a second participant (block 708).
[0088] In some embodiments, the first participant is a sensor
system attached to the vehicle. In other embodiments, the first
participant is a repair shop. Similarly, in some embodiments,
accessing the blockchain using the vehicle identifier may include:
searching, at the processor, the blockchain using the vehicle
identifier for a block which includes the vehicle identifier;
and/or verifying, at the processor, the vehicle identifier stored
at the block.
[0089] In other embodiments, if the vehicle identifier is not
stored at a block, the method may include generating, at the
processor, a vehicle record using the vehicle identifier; adding,
at the processor, the vehicle identifier, the driver identifier,
and the vehicle loss report to a vehicle loss transaction; linking,
at the processor, the vehicle loss transaction and the vehicle
record; adding, at the processor, the vehicle loss transaction to a
set of vehicle loss transactions; and/or adding, at the processor,
the set of vehicle loss transactions and the vehicle record to the
block.
[0090] In some embodiments, updating the block may include: adding,
at the processor, the vehicle identifier, the driver identifier,
and the vehicle loss report to a vehicle loss transaction; adding,
at the processor, the vehicle loss transaction to a set of vehicle
loss transactions; and/or adding, at the processor, the set of
vehicle loss transactions to the block.
[0091] In other embodiments, the method may include solving, at the
processor, a cryptographic puzzle corresponding to the block;
and/or 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.
[0092] 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 further
include receiving, at the processor, a repair notification from at
least a third participant, wherein the third participant is a
repair shop.
[0093] In some embodiments, the vehicle identifier may be used to
access the blockchain and identify a smart contract associated with
the vehicle. The vehicle identifier, and the vehicle loss history,
may be used to update the smart contract.
VIN Lifecycle
[0094] In one embodiment, the systems and methods are directed to
tracking a vehicle identifier on a blockchain maintained by a
plurality of participants. The vehicle identifier may be a Vehicle
Identification Number, more commonly referred to as a VIN. The VIN
may conform to a particular standard for Vehicle Identification
Numbers such as standards formulated and promulgated by, for
example, the Federal Motor Vehicle Safety Standards, the
International Standards Organization Standards, the Society of
Automotive Engineers Standards, and/or the Australian Design Rules
standards. These, and other, standards have particular information
requirements that must be met for vehicles that are manufactured,
imported/exported, or sold within particular jurisdictions.
[0095] Some of the information that these standards require for
disclosure in the VIN are: a world manufacturer identifier,
attributes of the vehicle (e.g., automotive platform used, the
model for the vehicle, the body style of the vehicle, any safety
features of the vehicle, self-driving features for the vehicle,
autonomous vehicle characteristics for the vehicle), a vehicle
model year, vehicle identifier information to identify that
particular vehicle, any software or software versions for systems
used by the vehicle or its components, and more particular
information about the vehicle manufacturer. VINs are used for many
types of vehicles, such as, for example, individual motor vehicles,
towed vehicles, motorcycles, scooters and mopeds. The VIN must be
reported to several agencies after the vehicle is manufactured, and
throughout the lifecycle of the vehicle. For example, the VIN must
be checked when a vehicle is sold, or when the vehicle is
destroyed. Any updates to the vehicle may impact the VIN, and
accordingly new information may need to be added to the blockchain,
such as an odometer reading. By instituting the process for
tracking the VIN from manufacture to salvage, aka "cradle to the
grave," on a blockchain significant time and resource improvements
can be obtained.
[0096] In one exemplary embodiment, the systems and methods
disclosed may be used by a participant to receive a vehicle
identifier notification, access a block stored on a blockchain to
determine if information for the vehicle corresponding to the
vehicle identifier notification is stored on the blockchain,
analyze the received vehicle identifier notification, perform any
necessary changes to information stored on the blockchain related
to the vehicle and/or the vehicle identifier notification, and
transmit the block where the vehicle information is stored, or a
vehicle identifier notification is stored, to another participant
on the network. In some cases, updating and transmitting the block
includes creating a new block with relevant information that will
be added to the blockchain.
[0097] In some embodiments, a node, such as the node 400 depicted
in FIG. 4, may be the recipient of the vehicle loss history, and
the node may be a part of a distributed ledger system, such as the
system 112 of FIG. 1B. In some embodiments, a graphical user
interface may be used to ensure that a user, or participant, may
interact with the data presented and more easily track as the
relevant data progresses through its process and is stored on the
blockchain. Additionally, as part of the process any relevant title
information or any liens that are held against the vehicle may be
part of the process.
Exemplary Computer-Implemented Method for VIN Lifecycle
[0098] FIG. 8 depicts an exemplary flow diagram 800 associated with
one aspect of the present disclosure for tracking a vehicle
identifier on a blockchain maintained by a plurality of
participants. In some embodiments, the network of participants may
be the nodes described above, for example node 400 depicted in FIG.
4. The blockchain used by the participants may be the blockchain
500 depicted in FIG. 5, whose operation is described in FIGS. 2A,
2B, and 5. The steps of the computer-implemented method 800 may be
performed by the nodes in the network of participants, such as the
nodes described in FIGS. 1A-4. The method 800 may include
additional, fewer, or alternative actions, including those
described elsewhere herein.
[0099] The exemplary flow diagram 800 may include (1) receiving, at
a processor coupled with a network interface, a vehicle identifier
notification from a participant (block 802); (2) accessing, at a
memory coupled with a processor, the blockchain using the vehicle
identifier notification (block 804); (3) updating, at the memory, a
block stored at the memory using the vehicle identifier
notification (block 806); and/or (4) transmitting, via the
processor coupled with the network interface, the block to at least
one other participant (block 808).
[0100] In some embodiments, the vehicle identifier notification
includes a notification source, a vehicle identifier set, and a
notification event. Further, in some embodiments of the method, the
vehicle identifier set includes a manufacturer, a descriptor
section, and an identifier section. Alternatively, the notification
event is a vehicle transfer, a vehicle accident, a vehicle repair
incident, a vehicle modification, or combinations thereof.
[0101] In some embodiments, accessing the blockchain using the
vehicle identifier notification may also include: verifying, at the
processor, a notification source for the vehicle identifier
notification; identifying, at the processor, an entry in the
blockchain corresponding to the vehicle identifier notification;
and/or accessing, at the memory, the entry in the blockchain
corresponding to the vehicle identifier notification.
[0102] In other embodiments, updating the blockchain using the
vehicle identifier notification may also include: verifying, at the
processor, that an entry in the blockchain corresponding to the
vehicle identifier notification exists; and/or wherein if the entry
does not exist, adding, at the memory, an entry in the blockchain
corresponding to the vehicle identifier notification.
[0103] An alternative embodiment of the computer-implemented method
may include, via one or more processors and/or transceivers,
tracking a vehicle identifier on a blockchain maintained by a
plurality of participants. The method may include: (1) receiving,
at a processor coupled with a network interface, a vehicle
identifier notification from a participant; (2) accessing, at a
memory coupled with a processor, the blockchain using the vehicle
identifier notification; (3) updating, at the memory, a block
stored at the memory using the vehicle identifier notification; (4)
generating, at the processor, a solution to a cryptographic puzzle
involving the block; and/or (5) transmitting, via the processor
coupled with the network interface, the block and the solution to
the cryptographic puzzle to at least one other participant.
[0104] In some embodiments, accessing the blockchain using the
vehicle identifier notification may also include: verifying, at the
processor, a notification source for the vehicle identifier
notification; identifying, at the processor, an entry in the
blockchain corresponding to the vehicle identifier notification;
and/or accessing, at the memory, the entry in the blockchain
corresponding to the vehicle identifier notification. Furthermore,
in some embodiments updating the blockchain using the vehicle
identifier notification may also include: verifying, at the
processor, that an entry in the blockchain corresponding to the
vehicle identifier notification exists; and wherein if the entry
does not exist, adding, at the memory, an entry in the blockchain
corresponding to the vehicle identifier notification.
[0105] In some embodiments, the vehicle identifier may be used to
access the blockchain and identify a smart contract associated with
the vehicle. The vehicle identifier, and the complimentary
notification, may be used to update the smart contract.
Exemplary VIN Chain or Blockchain Vin Registry
[0106] FIG. 9 depicts an exemplary VIN Chain 900. The VIN Chain may
be a Blockchain VIN Registry as discussed herein. The VIN for a
vehicle may act a key, or other provides access, to the Vin Chain
900, and in some embodiments may be hashed or encrypted.
[0107] In some embodiments, each VIN Chain 900 may be a blockchain
dedicated to an individual autonomous, smart, or other
(conventional) vehicle. The VIN Chain 900 may be required to
include the VIN for the vehicle. The VIN may be used to access,
identify, or verify the VIN Chain 900 or distributed ledger is
associated with the vehicle. The VIN Chain 900 may include one or
more additional data elements associated with the vehicle,
including those depicted in FIG. 9.
[0108] As shown in FIG. 9, the VIN Chain 900 or Blockchain VIN
Registry may have a VIN number associated with a particular vehicle
that acts as a key to accessing or updating the VIN Chain 900. The
VIN Chain 900 may have several data elements, including (1) owner
information, (2) title status (clean, salvaged, etc.), (3)
lienholder information, (4) lien payoff amount, (5) insurance
policy start and stop date, (6) insurance claim open and close
date, (7) build data (vehicle features), (8) maintenance and repair
dates and types, (9) telematics and odometer data, and/or other
data elements, including those discussed elsewhere herein.
[0109] For instance, the additional data elements may include
telematics data (such as driving, braking, speed, cornering,
stop/start, acceleration, etc.) associated with a particular driver
or vehicle. The insurance policy information may include UBI or
trip-based insurance details, such as location and mileage
information. The insurance policy information may also include
premiums, discounts, coverages, deductibles, limits, and/or
conditions.
[0110] As shown in FIG. 9, the owner information and title status
blocks in the VIN Chain 900 may be created or updated, and
subsequently accessed or read by manufacturers, dealerships, body
shops, DMVs, insurers, salvage vendors, individual smart vehicles,
vehicle owners, authorized 3.sup.rd parties, and/or other entities.
One use case for this type of information in a blockchain is title
tracking from "cradle to grave."
[0111] The lienholder and lien amount information blocks in the VIN
Chain 900 may by created or updated by lienholders or vehicle
owners, and subsequently accessed by insurers, lienholders, and/or
consumers. Use cases for this type of information in a blockchain
may be the claim payment for a total loss situation, and/or
automobile refinancing.
[0112] The insurance policy start and end data, and claim open and
close date information blocks in the VIN Chain 900 may be created
or updated by insurers, smart vehicles, or consumers, and
subsequently accessed or read by insurers, lienholders, other
vehicles, and consumers. The use cases for this type of information
in a blockchain may be providing evidence of insurance, detecting
buildup or fraud, and/or alternatively verifying the veracity of
insurance claims.
[0113] The build data (such as vehicle features or technology)
blocks in the VIN claim 900 may be created or updated by
manufactures or individual smart vehicles, and subsequently read by
other vehicles, insurers, consumers, other manufacturers, repair
shops, etc. Use cases for this type of information in a blockchain
may include insurance rating (e.g., vehicles having different
safety or technological systems that lower or otherwise impact risk
may be rated different), and improved repair cost estimates.
[0114] The maintenance and repair data blocks in the VIN claim 900
may be created or updated, and subsequently read or accessed by
body shops, repair facilities, insurers, individual smart or
connected vehicles, etc. A use case for this type of information in
a blockchain may include maintaining the vehicle history.
[0115] The telematics and/or odometer data blocks in the VIN Chain
900 may be created or updated by individual smart or connected
vehicles, and subsequently read by the vehicles, consumers,
insurers, or other 3.sup.rd parties. The telematics and/or odometer
data may be used to update smart contracts associated with UBI
(Usage-Based Insurance), which may provide insurance for a limited
amount of miles or time. Use cases for this type of information in
a blockchain may include claim processing, updating insurance
discounts, and/or issuing new or additional UBI smart
contracts.
Exemplary Vin Based Vehicle Services
[0116] FIG. 10 depicts exemplary VIN based vehicle services that
may be facilitated via the Blockchain VIN Registry. The VIN based
vehicle services may relate to (1) State Department of Motor
Vehicles (e.g., vehicle registration, title management, title
transfer, license plates, etc.); (2) Banking (e.g., lien payoff,
lien placement or transfer, etc.); (3) Insurance (e.g.,
verification of insurance, insurance quoting, claim handling, total
loss, etc.); (4) Automobile Manufacturers (e.g., VIN seeding,
recall notices, technology upgrades, updated software versions,
etc.); and/or (5) Salvage Vendors (e.g., title transfer, exchange
of monies, sensor or part valuation, vehicle or sensor auction,
total loss, etc.).
[0117] In one embodiment, transactions associated with a total loss
determination may be recorded on the Blockchain VIN Registry. The
transactions may include the VIN, and data related to the following
events or conditions: (1) a vehicle is involved in a crash with
another vehicle; (2) a blockchain may be used to determine active
insurance and another insurer; (3) determine if a lien is active,
and if so, the present payoff amount, and identify the bank or
other lender; (4) the insurer may send the payoff amount and the
bank may update the lien payoff and remove the lien on vehicle; (5)
title or e-title is transferred to an insurance company; (6) title
or e-title is later transferred to a salvage vendor; (7) the
salvage vendor may sell the vehicle; and/or (8) after which, title
or e-title is subsequently transferred to new owner, and/or the
insurer receives salvage proceeds from vehicle being sold.
[0118] In another embodiment, transactions associated with vehicle
manufacture and initial vehicle purchase/loan may be recorded on
the Blockchain VIN Registry. The transactions may include the VIN,
and vehicle or other data related to the following events or
conditions: (1) a new vehicle is manufactured, and VIN and
associated information is added to the blockchain; (2) a consumer
takes out a loan on the new (or another) vehicle, and a lien payoff
amount is placed on the blockchain; (3) the consumer receives title
or e-title to the vehicle through the State DMV; (4) the bank
places a lien on the vehicle title or e-title; and/or (5) auto
insurance is purchased for the driver, vehicle, and/or autonomous
vehicle.
[0119] In another embodiment, transactions associated with vehicle
refinancing may be recorded on the Blockchain VIN Registry. The
transactions may include the VIN, and vehicle or other data related
to the following events or conditions: (1) a vehicle may be
refinanced through an original or subsequent bank, (2) the bank may
query for a lien packet, (3) loan terms may be determined and
updated, (4) payoff amounts may be updated, etc.
Exemplary Virtual Claim Experience Using Blockchain
[0120] FIG. 11 depicts exemplary transactions that may be recorded,
logged, or updated in each block of a distributed ledger or
Blockchain VIN Registry 1100. The transactions may each include a
VIN for a particular vehicle, and one or more additional data
elements. The additional data elements may include (i)
identification a stakeholder or actor; (ii) tasks to be performed
or that have been completed; (iii) an output; and/or (iv) other
data, including that discussed elsewhere herein.
[0121] The stakeholder or actor data elements may indicate or
identify (1) vehicle owners, (2) repair facilities, (3) insurer,
(4) part suppliers, (5) logistics providers, and/or (6) rental
providers. Each stakeholder or actor data element may have a
corresponding task assigned, or a task be, or has been,
completed.
[0122] The task data elements for, and/or associated with, vehicle
owners may include (1) providing authorization to repair vehicle;
(2) authorizing payment to a repair facility; (3) paying a
deductible; and/or (4) completing any necessary forms.
[0123] The task data elements for, and/or associated with, repair
facilities may include (1) taking possession of vehicle; (2)
arranging for rental/substitute transportation; (3) securing
authorization to repair; (4) identifying potential areas of prior
damage/betterment; (5) developing a repair plan; (6) preparing an
estimate; (7) sending a listing of necessary parts to suppliers;
(8) finalizing parts order and ordering parts; (9) uploading an
estimate; (10) checking delivered parts versus parts ordered; (11)
repairing the vehicle; (12) providing a repair status updates to
the vehicle owner; (13) managing sublet repair tasks; (14)
detailing and delivering the vehicle; (15) providing the vehicle
owner with a repair warranty; and/or (16) sending a final repair
bill to the insurer.
[0124] The task data elements for, and/or associated with, insurers
may include (1) receiving a loss report; (2) determining coverage
and policy conditions; (3) vehicle triage; (4) sending an
assignment to the repair facility; (5) authorizing a rental vehicle
if applicable; (6) resolving any prior damage/betterment issues;
(7) sending an estimate and parts brochures to the vehicle owner;
(8) performing a vehicle inspection if and when required; and/or
(9) paying the final repair and any rental bills.
[0125] The task data elements for, and/or associated with, parts
suppliers may include (1) receiving notification of a parts
request; (2) competing for a parts sale; (3) packaging parts order
for delivery; and/or (4) working with logistics provider to load
parts.
[0126] The task data elements for, and/or associated with,
logistics providers may include (1) receiving parts delivery
notification; (2) aggregating a parts order; (3) verifying part
quality "grade" and/or checking for part damage; and/or (4)
delivering parts to repair facility.
[0127] The task data elements for, and/or associated with, rental
providers may include (1) providing replacement or rental vehicles;
and/or (2) sending a final rental bill.
[0128] The output data elements that may be associated with
transactions, and identified by VIN, and added to the Blockchain
VIN Registry may further include signed repair authorizations and
signed directions to pay (associated with the vehicle owner);
printed final repair bills and printed customer warranties
(associated with the repair facility); printed or mailed repair
estimates and printed or mailed alternative parts brochures
(associated with the insurer); archived parts orders (associated
with the parts supplier); archived shipping orders (associated with
the logistics provider); and final rental bills (associated with
the rental provider).
Proof of Insurance
[0129] FIG. 12 depicts an exemplary flow diagram 1200 associated
with one aspect of the present disclosure, in particular, verifying
proof of insurance on a vehicle using a blockchain. In some
embodiments, the network of participants may be the nodes described
above, for example node 400 depicted in FIG. 4. The blockchain used
by the participants may be the blockchain 500 depicted in FIG. 5,
whose operation is described in FIGS. 2A, 2B, and 5. The steps of
the computer-implemented method 1200 may be performed by the nodes
in the network of participants, such as the nodes described in
FIGS. 1A-4. The method 1200 may include additional, fewer, or
alternative actions, including those described elsewhere
herein.
[0130] Presently, most states have a law requiring motorists to
carry a certain amount of insurance on their vehicle. To enforce
this law, state authorities will often verify proof of insurance
when certain events happen, such as when a vehicle is registered,
or during a traffic stop or traffic accident. The state authorities
may be the Department of Motor Vehicles, other state agencies,
local law enforcement agencies, and federal agencies. To make it
possible for authorities to validate insurance coverage, the
majority of states have enacted laws that apply to the auto
insurance carriers who do business in their state, requiring the
carriers to submit regular, up-to-date information about their
current book of business. To verify that the insurance is active,
there's a complex data exchange occurring behind the scenes
involving state authorities and insurance carriers to get data to
the authorities attempting to validate the insurance. This data
exchange adds time, resources, and money to systems attempting to
validate insurance.
[0131] Alternatively, by using a blockchain based system, for
example using a blockchain based VIN registry, insurers submit
information on their currently insured VINs to the blockchain, and
various state authorities could then query it for evidence of
insurance. Such a system could allow for better fraud detection, as
a carrier could be notified if duplicate coverage is suspected on a
VIN. Similarly, insurers could report VIN numbers involved in a
claim, potentially tipping off other insurers of duplicate claim
fraud situations. The information on the blockchain could
potentially eliminate the need for insurance carrier tools that
allows for a person's (or vehicle's) insurance carrier to be
identified.
[0132] In addition to the VIN, other information related to the
driver's insurance may be accessible as part of the proof of
insurance process that utilizes a blockchain. For example, the
insured's name and address, the vehicle year and make, the policy
renewal dates, the insurance company name, and the insurance policy
number. These items can be thought of as information about the
insured, information about the vehicle, and information about the
policy. These pieces of information may be stored in the VIN
blockchain alongside the VIN, or in conjunction with the insurance
associated with the VIN.
[0133] The information stored on a VIN chain, or on a blockchain
used to verify proof of insurance, may be privileged information.
As such, participants in the blockchain may need sufficient
permission to join the blockchain and/or to view/access information
stored in the blockchain. State authorities may have access to the
blockchain, as well as insurers, and any potential lienholders that
own liens on the vehicles associated with the VINs. Similarly, auto
manufacturers may need access to the blockchain to create locks on
their vehicles that prevent the vehicle from starting if the
vehicle does not have insurance. These participants in the
blockchain may all provide the necessary computing power to
maintain the blockchain and operate nodes that confirm information
exchanged on the blockchain.
[0134] Additionally, some embodiments may utilize smart contracts
stored on the blockchain, and potentially controlled by
participating entities, to execute certain actions automatically.
For example, a smart contract may be able to provision insurance in
a temporary situation, such as insurance for a rental car. Smart
contracts may also be used to trigger alerts when a VIN is involved
in a claim and is underinsured, or has no insurance. Similarly, if
multiple claims are submitted for the same VIN, but from different
insurers a smart contract, upon receiving information about the
claims, could trigger automatic alerts to authorities or insurers
about the potentially fraudulent activity.
[0135] In one embodiment of the exemplary flow diagram 1200, the
computer-implemented method depicted may include steps such as (1)
receiving, at a processor coupled with a network interface, one or
more request datasets from one or more network participants (block
1202); (2) verifying, at the processor, that the one or more
network participants have permission to access information stored
on the permissioned blockchain using a requestor identifier
included in the request dataset for each network participant (block
1204); (3) when the one or more network participants have
permission, accessing, at a memory coupled with the processor, the
permissioned blockchain using a Vehicle Identification Number
included in each request dataset (block 1206A); (4) performing, at
the processor coupled with the memory, a verification of the
existence of data stored in the permissioned blockchain associated
with the Vehicle Identification Number (block 1208); (5)
transmitting, via the processor coupled with the network interface,
a request notification based upon the verification to the one or
more network participants (block 1210); and/or (6) when the one or
more network participants do not have permission, transmitting, via
the processor coupled with the network interface, a denial
notification to the one or more network participants (block
1206B).
[0136] In some embodiments, the plurality of network participants
comprises a law enforcement agency, a state regulatory agency, an
insurance agency, or combinations thereof. Similarly, in some
embodiments each request dataset further comprises a request id, a
request type, and a requestor type. In alternative embodiments, the
requestor identifier comprises a hash value associated with a
cryptographic key controlled by the corresponding network
participant.
[0137] In some embodiments, performing a verification of the
existence of data stored in the permissioned blockchain associated
with the Vehicle Identification Number, may include: identifying,
at the processor, a request type included in the request dataset,
wherein the request type comprises a verification request, a
modification request, or a new transaction request; when the
request type is a verification request, verifying, at the
processor, the existence of data associated with the Vehicle
Identification Number, when the data associated with the Vehicle
Identification Number does not exist, transmit a nonexistence
notification associated with the vehicle identifier to at least one
other network participant; when the request type is a modification
request, transmitting, at the processor coupled with the network
interface, a coverage dataset based upon the request dataset and
the modification request to at least one of network participant;
and/or when the request type is a new transaction request,
generating and transmitting, at the processor coupled with the
network interface, a coverage dataset based upon the request
dataset and the new transaction request to at least one of network
participant.
[0138] In other embodiments, the modification request comprises a
policy renewal, a policy change, or a policy transfer associated
with the Vehicle Identification Number. In yet other embodiments,
transmitting a request notification based upon the verification to
the one or more network participants, may include: generating, at
the processor, the request notification using the request type and
a success indicator indicating whether a coverage dataset was sent
to at one other network participant.
ADDITIONAL CONSIDERATIONS
[0139] 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.
[0140] An authoritative, trusted, immutable, distributed,
shareable, secure system may be needed to record if a human driver
is controlling a vehicle, and/or if the vehicle is acting
autonomously. The record may include crash sensor data to record
crash information correlating to driver control information.
[0141] Blockchain technology may be used to store the transactions
of control instances (from autonomous to human control to
autonomous, for example). These control instances may be stored as
they occur into blocks. Accordingly, this data may be included into
the distributed ledger environment of the blockchain. In this
environment, a consensus system may fix the events/blocks immutably
and securely.
[0142] In some scenarios, the blockchain may have public interfaces
that allow visibility into the data. In one embodiment, a private
blockchain interface may also be used by auto manufacturers, law
enforcement, insurers, and regulatory agencies.
[0143] An element of smart contracts may also be enabled in the
system. Depending on the sequence of events in the blockchain,
terms of the smart contract may be executed immediately, such as
sending a tow truck to the geolocation if tow assistance is a part
of the policy, filing a legal action by a subrogation team of an
insurer is brought against an auto manufacturer (for example, if an
accident occurs when the autonomous vehicle was in autonomous
control), conducting a policy review, filing a police report
request with the jurisdiction of the roadway, processing claims
awards made (for example, a partial payment if deductible is met,
to handle car rental or minor medical expense), sending a renewal
notice for the policy, and so on.
[0144] In some aspects, customers may opt-in to a rewards, loyalty,
or other program. The customer may allow a remote server, such as
an enforcement server, to collect sensor, telematics, vehicle,
mobile device, and other types of data discussed herein. With
customer permission or affirmative consent, the data collected may
be analyzed to provide certain benefits to customers. For instance,
insurance cost savings may be provided to lower risk or risk averse
customers. Discounts, including cryptocurrency, may be awarded to
accounts associated with the customer. The other functionality
discussed herein may also be provided to customers in return for
them allowing collection and analysis of the types of data
discussed herein, as well as participating in the validation of the
data discussed herein.
[0145] 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.
[0146] With the foregoing, a user may be an insurance customer who
may opt-in to 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 home functionality (or home occupant
preferences or preference profiles), smart 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 or
apartment occupants may receive discounts or insurance cost savings
related to home, renters, personal articles, auto, and other types
of insurance from the insurance provider.
[0147] In one aspect, 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, such as via direct or indirect wireless communication or
data transmission from a smart home controller, mobile device,
autonomous or smart vehicle, 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) home,
apartment, or vehicle occupants.
[0148] 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.
[0149] 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.
[0150] 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.
[0151] 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.
[0152] 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.
[0153] 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).
[0154] 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.
[0155] 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.
[0156] 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.
[0157] 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.
[0158] 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.
[0159] 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.
[0160] As used herein, the terms "includes," "comprising,"
"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 includes 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).
[0161] 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.
[0162] 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).
* * * * *