U.S. patent application number 14/202812 was filed with the patent office on 2014-09-11 for systems and methods for processing additional distance units for distance-based insurance policies.
This patent application is currently assigned to STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY. The applicant listed for this patent is STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY. Invention is credited to Todd Binion, Scott T. Christensen, Steven Cielocha, Christopher E. Gay, Gregory Hayward.
Application Number | 20140257866 14/202812 |
Document ID | / |
Family ID | 51229155 |
Filed Date | 2014-09-11 |
United States Patent
Application |
20140257866 |
Kind Code |
A1 |
Gay; Christopher E. ; et
al. |
September 11, 2014 |
SYSTEMS AND METHODS FOR PROCESSING ADDITIONAL DISTANCE UNITS FOR
DISTANCE-BASED INSURANCE POLICIES
Abstract
Methods and systems for processing distance-based insurance
policies for vehicles. According to aspects, a distance-based
insurance policy for a customer specifies an amount of distance
units for insured vehicle travel and has an associated policy term.
Before the expiration of the policy term, an insurance provider may
determine that few or no distance units remain. Accordingly, the
insurance provider may estimate an additional amount of distance
units that the customer may want to purchase. The insurance
provider can send an offer for the additional amount of distance
units to the customer and the customer can select to purchase the
additional amount of distance units.
Inventors: |
Gay; Christopher E.;
(Dallas, TX) ; Christensen; Scott T.; (Gibson
City, IL) ; Hayward; Gregory; (Bloomington, IL)
; Cielocha; Steven; (Bloomington, IL) ; Binion;
Todd; (Bloomington, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY |
Bloomington |
IL |
US |
|
|
Assignee: |
STATE FARM MUTUAL AUTOMOBILE
INSURANCE COMPANY
Bloomington
IL
|
Family ID: |
51229155 |
Appl. No.: |
14/202812 |
Filed: |
March 10, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61775652 |
Mar 10, 2013 |
|
|
|
Current U.S.
Class: |
705/4 |
Current CPC
Class: |
B60R 25/20 20130101;
H04W 4/40 20180201; B60C 1/00 20130101; G07C 5/00 20130101; B60Q
1/00 20130101; G07C 5/008 20130101; G06Q 30/0207 20130101; G06Q
40/00 20130101; G06Q 40/08 20130101; G06Q 30/0208 20130101 |
Class at
Publication: |
705/4 |
International
Class: |
G06Q 40/08 20120101
G06Q040/08 |
Claims
1. A computer-implemented method of processing insurance coverage,
the method comprising: facilitating, by one or more processors, a
purchase transaction with a customer for a distance-based insurance
policy associated with a vehicle, a coverage provided by the
insurance policy (1) is based on an expiration odometer value
defined as the sum of an initial odometer reading of the vehicle
and an amount of distance units specified by the distance-based
insurance policy, and (2) expires at the end of a policy term;
before the policy term expires, receiving a subsequent odometer
reading of the vehicle; based on the subsequent odometer reading,
determining, by the one or more processors, that the expiration
odometer value has been reached or is close to being reached; and
facilitating, by the one or more processors, an additional purchase
transaction with the customer for an additional amount of distance
units.
2. The computer-implemented method of claim 1, wherein receiving
the subsequent odometer reading of the vehicle comprises:
requesting an electronic device associated with the customer to
provide the subsequent odometer reading; and receiving the
subsequent odometer reading from the electronic device.
3. The computer-implemented method of claim 1, further comprising:
providing the expiration odometer value to an electronic device
associated with the customer, wherein receiving the subsequent
odometer reading of the vehicle comprises: automatically receiving
the subsequent odometer reading from the electronic device when the
electronic device detects that the expiration odometer value has
been reached or is close to being reached.
4. The computer-implemented method of claim 1, wherein facilitating
the additional purchase transaction with the customer comprises:
providing the customer with an offer for the additional amount of
distance units; and receiving an acceptance of the offer from the
customer.
5. The computer-implemented method of claim 4, wherein providing
the customer with the offer comprises: providing the customer with
the offer, wherein each of the additional amount of distance units
costs a different or same amount as each of the amount of distance
units.
6. The computer-implemented method of claim 1, wherein facilitating
the additional purchase transaction with the customer comprises:
responsive to determining that the expiration odometer value has
been reached or is close to being reached, automatically charging
an account of the customer for the additional amount of distance
units.
7. The computer-implemented method of claim 1, further comprising:
estimating the additional amount of distance units based on the
subsequent odometer reading and a time remaining on the policy
term.
8. A method on an electronic device associated with a vehicle, the
method comprising: facilitating, by one or more processors, a
purchase transaction with an insurance provider for a
distance-based insurance policy associated with the vehicle, a
coverage provided by the insurance policy (1) is based on an
expiration odometer value defined as the sum of an initial odometer
reading of the vehicle and an amount of distance units specified by
the distance-based insurance policy, and (2) expires at the end of
a policy term; before the policy term expires, detecting, by the
one or more processors, that the expiration odometer value has been
reached or is close to being reached; notifying the insurance
provider that the expiration odometer value has been reached or is
close to being reached; and facilitating, by the one or more
processors, an additional purchase transaction with the insurance
provider for an additional amount of distance units.
9. The method of claim 8, wherein detecting that the expiration
odometer value has been reached or is close to being reached
comprises: comparing a current odometer reading of the vehicle to
the expiration odometer value to determine that the current
odometer reading is close to, meets, or exceeds the expiration
odometer value.
10. The method of claim 9, further comprising: estimating the
additional amount of distance units based on the current odometer
reading of the vehicle and a time remaining on the policy term; and
providing an indication of the additional amount of distance units
to the insurance provider.
11. The method of claim 8, wherein notifying the insurance provider
that the expiration odometer value has been reached comprises:
providing a current odometer reading of the vehicle to the
insurance provider.
12. The method of claim 8, wherein facilitating the additional
purchase transaction with the customer comprises: receiving, from
the insurance provider, an offer for the additional amount of
distance units; receiving, from the customer via a user interface
of the electronic device, an acceptance of the offer; and
communicating the acceptance of the offer to the insurance
provider.
13. The method of claim 8, wherein facilitating the additional
purchase transaction with the customer comprises: receiving, from
the insurance provider, an indication of the additional amount of
distance units; and automatically purchasing the additional amount
of distance units.
14. A system for processing insurance coverage, comprising: a
communication module adapted to communicate data; a memory adapted
to store non-transitory computer executable instructions; and a
processor adapted to interface with the communication module,
wherein the processor is configured to execute the non-transitory
computer executable instructions to cause the processor to:
facilitate a purchase transaction with a customer for a
distance-based insurance policy associated with a vehicle, a
coverage provided by the insurance policy (1) is based on an
expiration odometer value defined as the sum of an initial odometer
reading of the vehicle and an amount of distance units specified by
the distance-based insurance policy, and (2) expires at the end of
a policy term, before the policy term expires, receive a subsequent
odometer reading of the vehicle via the communication module, based
on the subsequent odometer reading, determine that the expiration
odometer value has been reached or is close to being reached, and
facilitate an additional purchase transaction with the customer for
an additional amount of distance units.
15. The system of claim 14, wherein to receive the subsequent
odometer reading of the vehicle, the processor is configured to:
request an electronic device associated with the customer to
provide the subsequent odometer reading, and receive the subsequent
odometer reading from the electronic device via the communication
module.
16. The system of claim 14, wherein the processor is further
configured to execute the non-transitory computer executable
instructions to cause the processor to: provide, via the
communication module, the expiration odometer value to an
electronic device associated with the customer, and wherein to
receive the subsequent odometer reading of the vehicle, the
processor is configured to: automatically receive, via the
communication module, the subsequent odometer reading from the
electronic device when the electronic device detects that the
expiration odometer value has been reached or is close to being
reached.
17. The system of claim 14, wherein to facilitate the additional
purchase transaction with the customer, the processor is configured
to: provide, via the communication module, the customer with an
offer for the additional amount of distance units, and receive an
acceptance of the offer from the customer via the communication
module.
18. The system of claim 17, wherein each of the additional amount
of distance units costs a different or same amount as each of the
amount of distance units.
19. The system of claim 14, wherein to facilitate the additional
purchase transaction with the customer, the processor is configured
to: responsive to determining that the expiration odometer value
has been reached or is close to being reached, automatically charge
an account of the customer for the additional amount of distance
units.
20. The system of claim 14, wherein the processor is further
configured to execute the non-transitory computer executable
instructions to cause the processor to: estimate the additional
amount of distance units based on the subsequent odometer reading
and a time remaining on the policy term.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Application No. 61/775,652, filed Mar. 10, 2013, which is
incorporated by reference herein.
FIELD OF THE DISCLOSURE
[0002] The present disclosure generally relates to vehicle
insurance policies and, more particularly, to systems and methods
for facilitating offers associated with distance-based insurance
policies.
BACKGROUND
[0003] Vehicle or automobile insurance exists to provide financial
protection against physical damage and/or bodily injury resulting
from traffic accidents and against liability that could arise
therefrom. Typically, a customer purchases a vehicle insurance
policy for a policy rate having a specified term. In exchange for
payments from the insured customer, the insurer pays for damages to
the insured which are caused by covered perils, acts, or events as
specified by the language of the insurance policy. The payments
from the insured are generally referred to as "premiums," and
typically are paid on behalf of the insured over time at periodic
intervals. An insurance policy may remain (or have a status or
state of) "in-force" while premium payments are made during the
term or length of coverage of the policy as indicated in the
policy. An insurance policy may "lapse" (or have a status or state
of "lapsed"), for example, when premium payments are not being
paid, when a cash value of a policy falls below an amount specified
in the policy, or if the insured or the insurer cancels the
policy.
[0004] Various vehicle insurance providers offer "distance-based"
insurance whereby a customer purchases an insurance policy that
offers coverage for a specified amount of distance units. For
example, one distance-based insurance policy may offer coverage for
100 miles of travel by a particular vehicle. These vehicle
insurance policies may also have an associated policy term.
Referring back to the example, the 100 miles of coverage may have a
policy term of 1 month. However, there are situations in which the
customer may run out of a specified amount of distance units before
the expiration of the policy term. At this point, insurance
coverage for the customer may cease.
[0005] Accordingly, there is an opportunity for systems and methods
to offer additional distance units to customers having
distance-based vehicle insurance policies. In particular, there is
an opportunity for systems and methods to facilitate the purchase
of additional distance units in situations in which the policy is
still in force but no original distance units remain.
SUMMARY
[0006] In an embodiment, a computer-implemented method of
processing insurance coverage is provided. The method includes
facilitating, by one or more processors, a purchase transaction
with a customer for a distance-based insurance policy associated
with a vehicle, a coverage provided by the insurance policy (1) is
based on an expiration odometer value defined as the sum of an
initial odometer reading of the vehicle and an amount of distance
units specified by the distance-based insurance policy, and (2)
expires at the end of a policy term. The method further includes,
before the policy term expires, receiving a subsequent odometer
reading of the vehicle and, based on the subsequent odometer
reading, determining, by the one or more processors, that the
expiration odometer value has been reached. Additionally, the
method includes facilitating, by the one or more processors, an
additional purchase transaction with the customer for an additional
amount of distance units. In some embodiments, the method may
facilitate the additional purchase transaction before the
expiration odometer value has been reached, such as if the
expiration odometer value is close to being reached.
[0007] In another embodiment, a method on an electronic device
associated with a vehicle is provided. The method includes
facilitating, by one or more processors, a purchase transaction
with an insurance provider for a distance-based insurance policy
associated with the vehicle, a coverage provided by the insurance
policy (1) is based on an expiration odometer value defined as the
sum of an initial odometer reading of the vehicle and an amount of
distance units specified by the distance-based insurance policy,
and (2) expires at the end of a policy term. The method further
includes, before the policy term expires, detecting, by the one or
more processors, that the expiration odometer value has been
reached, notifying the insurance provider that the expiration
odometer value has been reached, and facilitating, by the one or
more processors, an additional purchase transaction with the
insurance provider for an additional amount of distance units.
[0008] In a further embodiment, a system for processing insurance
coverage is provided. The system includes a communication module
adapted to communicate data, a memory adapted to store
non-transitory computer executable instructions, and a processor
adapted to interface with the communication module. The processor
is configured to execute the non-transitory computer executable
instructions to cause the processor to facilitate a purchase
transaction with a customer for a distance-based insurance policy
associated with a vehicle, a coverage provided by the insurance
policy (1) is based on an expiration odometer value defined as the
sum of an initial odometer reading of the vehicle and an amount of
distance units specified by the distance-based insurance policy,
and (2) expires at the end of a policy term. The processor is
further configured to, before the policy term expires, receive a
subsequent odometer reading of the vehicle via the communication
module and, based on the subsequent odometer reading, determine
that the expiration odometer value has been reached. Additionally,
the processor is configured to facilitate an additional purchase
transaction with the customer for an additional amount of distance
units.
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] FIG. 1 depicts an example environment including components
and entities associated with processing distance-based vehicle
insurance policies in accordance with some embodiments.
[0011] FIG. 2 depicts an example diagram associated with
facilitating the purchase of additional distance units for existing
distance-based vehicle insurance policies in accordance with some
embodiments.
[0012] FIGS. 3A-3C depict example interfaces associated with
reviewing and selecting additional distance units to purchase in
accordance with some embodiments.
[0013] FIG. 4 depicts a flow diagram associated with an insurance
provider facilitating the purchase of additional distance units for
an existing distance-based vehicle insurance policy in accordance
with some embodiments.
[0014] FIG. 5 depicts a flow diagram associated with a customer
facilitating the purchase of additional distance units for an
existing distance-based vehicle insurance policy in accordance with
some embodiments.
[0015] FIG. 6 is a block diagram of a processing server in
accordance with some embodiments.
DETAILED DESCRIPTION
[0016] The novel systems and methods disclosed herein relate
generally to processing vehicle insurance policies. In particular,
the systems and methods relate to enabling customers to purchase
additional distance units associated with existing distance-based
insurance policies. According to certain aspects, a distance-based
insurance policy for a vehicle is defined by a certain amount of
distance units and a policy term or expiration time. Each distance
unit corresponds to a certain distance that is travelable by the
vehicle. Accordingly, the vehicle and a customer associated with
the vehicle (e.g., the vehicle owner or operator) may be covered by
the insurance policy while the policy term is in force and as long
as the vehicle does not travel in excess of the amount of distance
units.
[0017] There may be situations, however, in which a customer having
a distance-based insurance policy will run out of distance units
before the end of the policy term. In these situations, any
additional distance units that the customer drives in the vehicle
will not be covered under the original distance-based insurance
policy. According to the present embodiments, the systems and
methods are configured to enable customers to purchase additional
distance units before the expiration of the policy term so that the
customer is continuously covered by the insurance policy. In
particular, the customer, vehicle, or insurance provider may
monitor the amount of original distance units during the policy
term. If at some point there are few or no remaining distance
units, the insurance provider may offer the customer additional
distance units, which the customer can select to purchase.
[0018] The systems and methods therefore offer a benefit to
customers by enabling customers to purchase what is effectively
additional distance-based vehicle insurance in situations in which
the customers may not be otherwise covered. Therefore, the
customers may continuously have vehicle insurance when the
customers may not have otherwise foreseen using all original
distance units during a policy term. Further, insurance providers
may be able to attract more customers and/or process more insurance
policies.
[0019] Although the following text sets forth a detailed
description of numerous different embodiments, it should be
understood that the legal scope of the invention is defined by the
words of the claims set forth at the end of this patent. The
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
could implement numerous alternate embodiments, using either
current technology or technology developed after the filing date of
this patent, which would still fall within the scope of the
claims.
[0020] FIG. 1 depicts an example environment 100 associated with
processing distance-based vehicle insurance policies. Although FIG.
1 depicts certain entities, components, and devices, it should be
appreciated that additional or alternate entities and components
are envisioned.
[0021] As illustrated in FIG. 1, the environment 100 includes a
vehicle 105 that may be any type of car, automobile, truck,
motorcycle, fleet of vehicles, marine vessel, or other vehicle
capable of being driven or operated by a driver or operator. The
vehicle 105 has an electronic device 106 associated therewith. In
some cases, the electronic device 106 may be installed as an
on-board dash of the vehicle 105, such as part of an original
equipment manufacturer (OEM) installation on the vehicle 105. In
other cases, the electronic device 106 may belong to a driver or
operator of the vehicle 105 (generally, a "vehicle operator"). For
example, the electronic device 106 may be a smartphone of the
vehicle operator. It should be appreciated that other types of
electronic devices are envisioned, such as notebook computers,
tablets, GPS devices, and/or the like.
[0022] The electronic device 106 can be configured to communicate
with an insurance provider 110 via a network 120. The network 120
can facilitate any type of data communication via any standard or
technology (e.g., GSM, CDMA, TDMA, WCDMA, LTE, EDGE, OFDM, GPRS,
EV-DO, UWB, IEEE 802 including Ethernet, WiMAX, and/or others). The
insurance provider 110 can be any individual, group of individuals,
company, corporation, or other type of entity that can offer and
issue insurance policies for customers, such as a vehicle insurance
policy for the vehicle 105. According to embodiments, the insurance
provider 110 can include one or more processing server(s) 125
configured to facilitate the functionalities as discussed herein.
Although FIG. 1 depicts the processing server 125 as a part of the
insurance provider 110, it should be appreciated that the
processing server 125 can be separate from (and connected to or
accessible by) the insurance provider 110.
[0023] According to embodiments, the insurance provider 110 may
offer and ultimately issue, to the vehicle operator, a
distance-based insurance policy associated with the vehicle 105. In
particular, the distance-based insurance policy may provide
coverage for the vehicle operator and/or the vehicle 105.
Specifically, the distance-based insurance policy provides coverage
for a certain amount of distance units to be driven by the vehicle
105. For example, a distance-based insurance policy may provide
coverage for 50 miles, 500 miles, or other distances.
[0024] Generally, when the vehicle operator purchases a
distance-based insurance policy from the insurance provider 110,
the vehicle operator will provide an initial odometer reading of
the vehicle 105 to the insurance provider 110. In some cases, the
insurance provider 110 may obtain the initial odometer reading
directly from the electronic device 106 or another device
associated with the vehicle 105 (e.g., an on-board component).
Accordingly, the distance-based insurance policy has an "expiration
odometer value" defined as the sum of the initial odometer reading
and the specified amount of distance units covered by the insurance
policy. For example, if the initial odometer reading is 80,500
miles and the specified amount of distance units is 500 miles, the
expiration odometer value is 81,000 miles.
[0025] The distance-based insurance policies may also specify an
expiration date or time, or policy term, within which the vehicle
operators may use their distance units (e.g., by driving their
vehicles). For example, if a distance-based insurance policy
insures 500 miles and has a policy term of 6 months, then the
vehicle operator (and/or the vehicle 105, depending on the
coverage) is insured for an operating distance of 500 miles
assuming that those miles are driven within the 6 month policy
term. In embodiments, the unused distance units may expire or lapse
upon expiration of the policy term. Therefore, absent a renewal or
purchase of additional distance units, the vehicle operator and/or
the vehicle 105 will not be insured past the policy term, even if
there remain any unused distance units. For example, if a
distance-based insurance policy is in force starting on January 1
and has a 6 month policy term, the expiration date of the policy is
June 30, whereby neither the vehicle operator nor the vehicle 105
is insured according to the policy beginning on July 1, even if
there are unused distance units.
[0026] Similarly, a vehicle operator may use up all of the allotted
distance units before the expiration of the policy term. In this
case, the vehicle operator (and/or the vehicle 105) may not be
covered under an insurance policy if there are no remaining
distance units, even if the insurance policy is still in force.
Accordingly, the vehicle operator may want to purchase additional
distance units or otherwise be presented with an option to purchase
additional distance units. In embodiments, the insurance provider
110 (or the electronic device 106) can determine when there are no
remaining distance units during a policy term. The insurance
provider 110 can also generate a quote for an additional amount of
distance units, and provide the quote to the vehicle operator. In
embodiments, the additional amount of distance units may be based
on the amount of used distance units and a time remaining in the
policy term. The vehicle operator can review the quote, and select
to purchase the additional amount of distance units or request a
modified quote for a different amount of distance units. In some
embodiments, the insurance provider 110 (or the electronic device)
can automatically charge the vehicle operator (or automatically
process a payment) for the additional distance units in response to
determining that no original distance units remain.
[0027] The processing server 125 can be coupled to a database 115
configured to store data associated with vehicle insurance
policies. In particular, the database 115 is configured to store
and maintain accounts for the vehicle operators, whereby the
accounts specify the terms of the distance-based insurance
policies. The processing server 125 may be configured to interface
with the database 115 to monitor expiration dates of the
distance-based insurance policies, as well as process the purchase
of additional distance units.
[0028] Referring to FIG. 2, illustrated is a signal diagram 200
associated with managing distance units associated with
distance-based insurance policies. In particular, FIG. 2 includes a
vehicle/customer device 206 (such as the electronic device 106 as
described with respect to FIG. 1) and an insurance provider 210
(such as the insurance provider 110 as described with respect to
FIG. 1). It should be appreciated that the vehicle/customer device
206 may include any electronic device associated with the vehicle
(e.g., an on-board dash system) and/or any electronic device
associated with a user/driver/operator of the vehicle (e.g., a
vehicle operator's smartphone, laptop, etc.). Although only one
vehicle/customer device 206 is depicted in FIG. 2, it should be
appreciated that the insurance provider 210 may communicate with
multiple vehicle/customer devices 206 to manage distance units
associated with distance-based insurance policies.
[0029] The signal diagram 200 may begin when a customer (i.e.,
vehicle operator) uses the vehicle/customer device 206 to send a
request (222) to the insurance provider 210 for a distance-based
insurance policy. Generally, the distance-based insurance policy
provides insurance coverage for the vehicle and the vehicle
operator for a set amount of distance units (e.g., miles,
kilometers, etc.). The customer may use the vehicle/customer device
206 to provide (224) an initial odometer reading, and optionally a
desired amount of distance units and a desired policy term. For
example, the customer may request an insurance policy for 1,000
miles having a policy term of 6 months. It should be appreciated
that the customer may provide the initial odometer reading manually
(e.g., by entering the odometer reading into an application of the
vehicle/customer device 206) or via an indirect channel (e.g.,
taking a picture of the odometer in the vehicle and transmitting
the picture to the insurance provider 110). Further, the
vehicle/customer device 206 may be configured to automatically
provide the initial odometer reading to the insurance provider 210.
It should be appreciated that other techniques and channels for
transmitting the initial odometer reading are envisioned.
[0030] The insurance provider 210 may assess an underwriting risk
of the customer based on various customer data, as known in the
art, and provide an insurance quote to the vehicle/customer device
206. The insurance quote may offer a distance-based insurance
policy with terms that are the same as or different from the
originally-requested terms (e.g., fewer or more distance units,
shorter or longer policy term, etc.). The vehicle/customer device
206 and the insurance provider 210 may facilitate (226) a purchase
transaction for the distance-based insurance policy according to
the insurance quote, after which the distance-based insurance
policy may be deemed active. Accordingly, the initial odometer
reading may serve as the "starting point" for the insurance policy.
The insurance provider 210 can calculate and record (227) an
expiration odometer reading, which can be defined as the sum of the
initial odometer reading and the amount of distance units specified
by the insurance policy. In an optional embodiment, the insurance
provider 210 can provide (228) the expiration odometer value to the
vehicle/customer device 206 so that the vehicle/customer device 206
may monitor the expiration odometer value. It should be appreciated
that the customer may facilitate the purchase transaction and the
terms of the distance-based insurance policy via other techniques
or channels, such as via a phone call with the insurance provider
210 or via meeting with an agent of the insurance provider 210.
[0031] The insurance provider 210 and/or the vehicle/customer
device 206 can monitor the remaining amount of distance units
throughout the policy term and before the policy term expires,
according to various techniques. In one embodiment, the insurance
provider 210 can optionally request (230) the vehicle/customer
device 206 for a subsequent odometer reading. The vehicle/customer
device 206 can provide (232) the subsequent odometer reading to the
insurance provider 210, for example via one or more manual or
automatic techniques as discussed herein. Based on the expiration
odometer value and the subsequent odometer reading, the insurance
provider 210 can determine (234) whether the expiration odometer
value has been reached (i.e., whether the amount of distance units
has been exhausted). For example, if the initial odometer reading
was 12,000 miles, the insurance policy covered 1,000 miles
(resulting in an expiration odometer value of 13,000 miles), and
the subsequent odometer reading meets or exceeds 13,000 miles, then
no miles remain from the insurance policy. In some embodiments, the
insurance provider 210 can determine that the expiration odometer
value is close to being reached. For example, the expiration
odometer value may be close to being reached if a difference
between the subsequent odometer reading and the expiration odometer
value is below a threshold amount (e.g., 100 distance units, 50
distance units, ten (10) distance units, five (5) distance units,
etc.). The threshold amount may be based on the original amount of
distance units. For example, if the original amount of distance
units is 1,000, then the threshold amount may be 5% of that amount
(or 50 distance units). If the insurance provider 210 determines
that the expiration odometer value has not been reached ("NO"), the
insurance provider 210 (and/or the vehicle/customer device 206) can
return to monitoring the remaining amount of distance units.
[0032] Although not illustrated in FIG. 2, it should be appreciated
that the vehicle/customer device 206 can monitor the odometer of
the vehicle during the policy term and detect when the amount of
distance units is exhausted. Responsive to the detection, the
vehicle/customer device 206 can notify the insurance provider 210
that no distance units remain. Further, although the embodiments
herein describe monitoring for distance unit expiration (or
determining when the distance units expire), it should be
appreciated that certain functionalities may trigger when the
distance units are close to running out or expiring. For example,
the insurance provider 210 may determine that the customer has 10
remaining miles, and may at that point generate an offer for
additional miles. Therefore, the customer may be given more time to
decide whether to purchase additional distance units as well as
more time to facilitate the purchase of the additional distance
units.
[0033] If the insurance provider determines that the expiration
odometer value has been reached ("YES") (or if the vehicle/customer
device 206 detects that no distance units remain), the insurance
provider 210 can estimate 236 an additional amount of distance
units that the customer may wish to purchase. In some cases, the
customer may want to purchase an amount of additional distance
units that will last until the end of the policy term but will
result in a minimum amount of distance units that remain at the end
of the policy term (i.e., an amount of additional distance units
that is commensurate with the customer's pace in exhausting the
original distance units). Accordingly, the insurance provider 210
can estimate the additional amount of distance units based on the
subsequent odometer reading (and accordingly the original amount of
distance units) as well as the time remaining in the policy term.
For example, if the customer originally purchased 1,000 miles for a
6-month policy term and exhausted all of the 1,000 miles after 3
months, then the insurance provider 210 can estimate that the
customer may need another 1,000 miles to last for the remaining 3
months of the 6-month policy term. It should be appreciated that
the vehicle/customer device 206 may similarly estimate the
additional amount of distance units using the available data.
[0034] The insurance provider 210 can generate an offer for the
additional amount of distance units and provide (238) the offer to
the vehicle/customer device 206. The offer may be an extension of
the original distance-based insurance policy, or may constitute a
separate distance-based insurance policy. Further, the offer can
include a price or cost of the additional amount of distance units,
whereby the price or cost may be based on various factors such as
the amount of additional distance units, the time remaining in the
policy term, and/or other factors. It should be appreciated that
the cost of each of the additional amount of distance units may be
the same as or different from the cost of each of the original
distance units. In embodiments, the additional amount of distance
units may expire at the end of the original policy term, however it
should be appreciated that the additional amount of distance units
may have a different policy term than the original policy term.
[0035] The customer may use the vehicle/customer device 206 to
select (240) the offer for the additional distance units. In some
embodiments, the customer may use the vehicle/customer device 206
to request a different amount of additional distance units (which
the insurance provider 210 may or may not approve, or which may or
may not result in changes to the quote). The vehicle/customer
device 206 and the insurance provider 210 may facilitate (242) a
purchase transaction for the additional amount of distance units
according to the insurance quote, after which the distance-based
insurance policy may once again be deemed active. In some
embodiments, the vehicle/customer device 206 can be configured to
automatically purchase additional distance units when it is
determined that the original amount of distance units have expired.
Similarly, the insurance provider 210 may automatically charge the
customer for the additional distance units when the insurance
provider 210 determines that no original distance units remain.
[0036] It should be appreciated that the customer may purchase
additional distance units at any point during the policy term of
the insurance policy. For example, the customer may envision going
on a long road trip that necessitates more miles than are in a
customer account. The customer may therefore explicitly request
additional distance units which the insurance provider may offer to
the customer for purchase.
[0037] FIGS. 3A-3C illustrate example interfaces associated with
purchasing additional distance units for a distance-based vehicle
insurance policy. A vehicle or a customer device (e.g., an on-board
dash system, a smartphone, etc.) may be configured to display the
interfaces and receive selections and inputs via the interfaces.
For example, a dedicated application that is configured to operate
on the vehicle or consumer device may display the interfaces. It
should be appreciated that the interfaces are merely examples and
that alternative or additional content is envisioned. Further, it
should be appreciated that alternative devices or machines may
display the example interfaces.
[0038] FIG. 3A illustrates an interface 348 that notifies a
customer that all of an original amount of distance units have
expired. In embodiments, an insurance provider may notify the
vehicle/customer device when the distance units have expired, which
can cause the vehicle/customer device to display the interface 348.
The interface 348 also indicates an option for the user to purchase
additional distance units ("Would you like to purchase additional
miles?"). The interface 348 includes a "no thanks" selection 349
that enables the customer to exit the purchasing functionality and
a "yes" selection 350 that enables the customer to proceed to
purchase additional distance units. Although not illustrated in
FIG. 3A, it should be appreciated that the insurance provider may
provide a notification to the customer that the original amount of
distance units are about to expire (such as if the remaining amount
of distance units falls below a certain threshold). In this case,
the notification can also enable the customer to purchase
additional distance units so as to prevent the amount of distance
units from expiring.
[0039] FIG. 3B illustrates an interface 352 that the
vehicle/customer device may display in response to the user
selecting the yes selection 350 of FIG. 3A. The interface 352
indicates an amount of additional distance units available for
purchase and that expire at the end of the policy term. In
particular, the interface 352 indicates the availability to
purchase 500 additional miles for $25.00. The insurance provider
may estimate the amount of additional distance units and determine
the price for the additional distance units according to the
techniques discussed herein. The interface 352 also includes a "no
thanks" selection 353 that enables the customer to exit the
purchasing functionality and a "yes" selection 355 that enables the
customer to proceed to purchase additional distance units. Further,
the interface 352 includes a modify selection 354 that enables the
customer to modify one or more of the terms of the additional
distance units. For example, the customer may request the insurance
provider for fewer or more additional distance units (which may or
may not result in a change in price for the additional distance
units).
[0040] FIG. 3C illustrates an interface 357 that the
vehicle/customer device may display in response to the user
selecting the yes selection 355 of FIG. 3B. Of course, there may be
intermediate interfaces that enable the customer to facilitate the
purchase transaction for the additional distance units (e.g., an
interface to input payment information). The interface 357
indicates that the purchase of the additional distance units has
been processed, and that the customer has additional distance units
added to his or her account. The interface 357 includes an "okay"
selection 358 that enables the customer to dismiss the interface
357.
[0041] Referring to FIG. 4, depicted is a block diagram of an
example method 400 for enabling a customer to purchase additional
distance units for a distance-based insurance policy associated
with a vehicle. The method 400 may be facilitated between the
insurance provider 110 (and specifically the processing server 125)
as depicted in FIG. 1 and a customer associated with the vehicle.
The customer may access any type of electronic or computing device
(such as the electronic device 106) to provide data and make
appropriate selections.
[0042] The insurance provider can receive (block 405), from the
customer, a request for a distance-based insurance policy
associated with the vehicle, as well as an initial odometer reading
of the vehicle. In some embodiments, the request can include a
desired amount of distance units for the distance-based insurance
policy. The insurance provider can facilitate (block 410) a
purchase transaction with the customer for the distance-based
insurance policy, where the distance-based insurance policy expires
at the end of a policy term (i.e., has a pre-determined expiration
time). The distance-based insurance policy also specifies an amount
of distance units (which may be the same as or different from the
desired amount of distance units). The insurance provider can
calculate and record (block 415) an expiration odometer value. In
particular, the expiration odometer value can be defined as a sum
of the initial odometer reading and the amount of distance units
specified by the insurance policy. The insurance provider can also
provide the expiration odometer value to the customer.
[0043] At block 420, the insurance provider can optionally request
a subsequent odometer reading of the vehicle before the end of the
policy term. According to embodiments, the subsequent odometer
reading can be automatically retrieved or manually inputted by the
customer. In either case, the insurance provider can receive (block
425) the subsequent odometer reading of the vehicle. In some
embodiments, the customer can automatically provide the subsequent
odometer reading without the insurance provider having to send the
request.
[0044] The insurance provider can determine (block 430) whether the
expiration odometer value has been reached. In particular, the
insurance provider can compare the subsequent odometer reading with
the expiration odometer value to determine whether the subsequent
odometer reading meets or exceeds the expiration odometer value.
The insurance provider can also determine when the expiration
odometer value is close to being reached. For example, the
difference between the subsequent odometer reading and the
expiration odometer value can fall below a threshold amount. In
some embodiments, the customer may automatically provide the
subsequent odometer reading when the expiration odometer value is
reached so that the insurance provider need not perform the
determination of block 430.
[0045] If the insurance provider determines that the expiration
odometer value has not been reached ("NO"), processing can return
to block 420 or proceed to any other functionality. It should be
appreciated that the insurance provider may then periodically
request the subsequent odometer reading from the customer. If the
insurance provider determines that the expiration odometer value
has been reached ("YES"), processing can proceed to block 435 at
which the insurance provider can estimate an additional amount of
distance units for the policy term. In particular, the insurance
provider can estimate the additional amount of distance units based
on the subsequent odometer reading and a time remaining on the
policy term.
[0046] The insurance provider can provide (block 440) the customer
with an offer for the additional amount of distance units. In some
embodiments, the additional amount of distance units may have an
average cost that is more (or less) than the average cost of the
original distance units. Further, the additional amount of distance
units may also expire at the end of the policy term, or they may
have a different policy term. The customer can accept the offer and
the insurance provider can facilitate (block 445) an additional
purchase transaction with the customer for the additional amount of
distance units. In some cases, the insurance provider may
automatically facilitate the additional purchase transaction with
the customer in response to the customer reaching the expiration
odometer value.
[0047] Referring to FIG. 5, depicted is a block diagram of an
example method 500 for purchasing, from an insurance provider,
additional distance units for a distance-based insurance policy
associated with a vehicle. The method 500 may be facilitated by a
customer associated with the vehicle. The customer may access any
type of electronic or computing device (such as the electronic
device 106) to communicate with an insurance provider, such as the
insurance provider 110 (and specifically the processing server 125)
as depicted in FIG. 1.
[0048] The customer can request (block 505) the insurance provider
for a distance-based insurance policy associated with the vehicle,
where the request includes an initial odometer reading of the
vehicle. In some embodiments, the request can indicate a desired
amount of distance units for the distance-based insurance policy.
The customer can facilitate (block 510) a purchase transaction with
the insurance provider for the distance-based insurance policy,
where the distance-based insurance policy expires at the end of a
policy term (i.e., has a pre-determined expiration time). The
distance-based insurance policy also specifies an amount of
distance units (which may be the same as or different from the
desired amount of distance units). The customer can receive and
record (block 515) an expiration odometer value. In particular, the
expiration odometer value can be defined as a sum of the initial
odometer reading and the amount of distance units specified by the
insurance policy. In some embodiments, the customer may
automatically calculate the expiration odometer value.
[0049] The customer may monitor (block 520) or identify the current
odometer value of the vehicle. The customer can also determine
(block 525), based on the current odometer value, whether the
expiration odometer value has been reached. In particular, the
customer can compare the current odometer reading to the expiration
odometer value to determine whether the current odometer reading
meets or exceeds the expiration odometer value. It should be
appreciated that the customer may automatically determine when the
current odometer reading reaches the expiration odometer value. In
some embodiments, the customer may determine when the current
odometer reading is close to reaching the expiration odometer
value, such as when the difference between the current odometer
reading and the expiration odometer value falls below a threshold
amount.
[0050] If the customer determines that the expiration odometer
value has not been reached ("NO"), processing can return to block
520 or proceed to any other functionality. If the customer
determines that the expiration odometer value has been reached
("YES"), processing can proceed to block 530 at which the customer
can estimate an additional amount of distance units for the policy
term. In particular, the customer can estimate the additional
amount of distance units based on the current odometer reading and
a time remaining on the policy term. The customer can provide
(block 535) the insurance provider with an indication of the
additional amount of distance units. According to embodiments, the
insurance provider can generate a quote for the additional amount
of distance units.
[0051] The customer can receive (block 540) an offer for the
additional amount of distance units from the insurance provider. In
some embodiments, the additional amount of distance units may have
an average cost that is more (or less) than the average cost of the
original distance units. Further, the additional amount of distance
units may also expire at the end of the policy term, or they may
have a different policy term. The customer can accept the offer for
the additional distance units, for example via a user interface of
the electronic device. Responsive to accepting the offer, the
customer can facilitate (block 545) an additional purchase
transaction with the insurance provider for the additional amount
of distance units. In some cases, the customer may automatically
purchase the additional amount of distance units in response to the
vehicle reaching the expiration odometer value.
[0052] FIG. 6 illustrates a diagram of an example processing server
625 (such as the processing server 125 discussed with respect to
FIG. 1) in which the functionalities as discussed herein may be
implemented. It should be appreciated that the processing server
625 can be associated with an insurance provider, as discussed
herein.
[0053] The processing server 625 can include a processor 622 as
well as a memory 678. The memory 678 can store an operating system
679 capable of facilitating the functionalities as discussed herein
as well as a set of applications 675 (i.e., machine readable
instructions). For example, one of the set of applications 675 can
be a policy processing application 684 configured to facilitate the
offering and purchase of distance-based insurance policies. It
should be appreciated that other applications are envisioned.
[0054] The processor 622 can interface with the memory 678 to
execute the operating system 679 and the set of applications 675.
According to embodiments, the memory 678 can also include customer
account information 680 that includes information related to
accounts of customers, including insurance policies and credits
associated therewith. The policy processing application 684 may
interface with the customer account information 680 to retrieve
relevant information that the policy processing application 684 may
use to process insurance policies and terms associated therewith.
The memory 678 can include one or more forms of volatile and/or
non-volatile, fixed and/or removable memory, such as read-only
memory (ROM), electronic programmable read-only memory (EPROM),
random access memory (RAM), erasable electronic programmable
read-only memory (EEPROM), and/or other hard drives, flash memory,
MicroSD cards, and others.
[0055] The processing server 625 can further include a
communication module 677 configured to communicate data via one or
more networks 620. According to some embodiments, the communication
module 677 can include one or more transceivers (e.g., WWAN, WLAN,
and/or WPAN transceivers) functioning in accordance with IEEE
standards, 3GPP standards, or other standards, and configured to
receive and transmit data via one or more external ports 676. For
example, the communication module 677 can send, via the network
620, requests for odometer information and/or credit options and
receive relevant data and selections. The processing server 625 may
further include a user interface 681 configured to present
information to a user and/or receive inputs from the user. As shown
in FIG. 6, the user interface 681 includes a display screen 682 and
I/O components 683 (e.g., ports, capacitive or resistive touch
sensitive input panels, keys, buttons, lights, LEDs, speakers,
microphones). According to embodiments, the user may access the
processing server 625 via the user interface 681 to process
insurance policies and/or perform other functions. In some
embodiments, the processing server 625 can perform the
functionalities as discussed herein as part of a "cloud" network or
can otherwise communicate with other hardware or software
components within the cloud to send, retrieve, or otherwise analyze
data.
[0056] In general, a computer program product in accordance with an
embodiment includes a computer usable storage medium (e.g.,
standard random access memory (RAM), an optical disc, a universal
serial bus (USB) drive, or the like) having computer-readable
program code embodied therein, wherein the computer-readable
program code is adapted to be executed by the processor 622 (e.g.,
working in connection with the operating system 679) to facilitate
the functions as described herein. In this regard, the program code
may be implemented in any desired language, and may be implemented
as machine code, assembly code, byte code, interpretable source
code or the like (e.g., via C, C++, Java, Actionscript,
Objective-C, Javascript, CSS, XML). In some embodiments, the
computer program product may be part of a cloud network of
resources.
[0057] 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.
[0058] 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 non-transitory, machine-readable medium) 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 example 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.
[0059] 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.
[0060] 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.
[0061] Hardware modules can 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 can operate on a resource (e.g.,
a collection of information).
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] 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 cooperate or interact with each other. The embodiments
are not limited in this context.
[0068] It should also be understood that, unless a term is
expressly defined in this patent using the sentence "As used
herein, the term `______` is hereby defined to mean . . . " or a
similar sentence, there is no intent to limit the meaning of that
term, either expressly or by implication, beyond its plain or
ordinary meaning, and such term should not be interpreted to be
limited in scope based on any statement made in any section of this
patent (other than the language of the claims). To the extent that
any term recited in the claims at the end of this disclosure is
referred to in this disclosure in a manner consistent with a single
meaning, that is done for sake of clarity only so as to not confuse
the reader, and it is not intended that such claim term be limited,
by implication or otherwise, to that single meaning. Finally,
unless a claim element is defined by reciting the word "means" and
a function without the recital of any structure, it is not intended
that the scope of any claim element be interpreted based on the
application of 35 U.S.C. .sctn.112, sixth paragraph.
[0069] The term "insurance policy," as used herein, generally
refers to a contract between an insurer and an insured. In exchange
for payments from the insured, the insurer pays for damages to the
insured which are caused by covered perils, acts or events as
specified by the language of the insurance policy. The payments
from the insured are generally referred to as "premiums," and
typically are paid on behalf of the insured upon purchase of the
insurance policy or over time at periodic intervals. The amount of
the damages payment is generally referred to as a "coverage amount"
or a "face amount" of the insurance policy. An insurance policy may
remain (or have a status or state of) "in-force" while premium
payments are made during the term or length of coverage of the
policy as indicated in the policy. An insurance policy may "lapse"
(or have a status or state of "lapsed"), for example, when the
parameters of the insurance policy have expired, when premium
payments are not being paid, when a cash value of a policy falls
below an amount specified in the policy (e.g., for variable life or
universal life insurance policies), or if the insured or the
insurer cancels the policy.
[0070] The terms "insurer," "insuring party," and "insurance
provider" are used interchangeably herein to generally refer to a
party or entity (e.g., a business or other organizational entity)
that provides insurance products, e.g., by offering and issuing
insurance policies. Typically, but not necessarily, an insurance
provider may be an insurance company.
[0071] Although the embodiments discussed herein relate to vehicle
or automobile insurance policies, it should be appreciated that an
insurance provider may offer or provide one or more different types
of insurance policies. Other types of insurance policies may
include, for example, homeowners insurance; condominium owner
insurance; renter's insurance; life insurance (e.g., whole-life,
universal, variable, term); health insurance; disability insurance;
long-term care insurance; annuities; business insurance (e.g.,
property, liability, commercial auto, workers compensation,
professional and specialty liability, inland marine and mobile
property, surety and fidelity bonds); boat insurance; insurance for
catastrophic events such as flood, fire, volcano damage and the
like; motorcycle insurance; farm and ranch insurance; personal
article insurance; personal liability insurance; personal umbrella
insurance; community organization insurance (e.g., for
associations, religious organizations, cooperatives); and other
types of insurance products. In embodiments as described herein,
the insurance providers process claims related to insurance
policies that cover one or more properties (e.g., homes,
automobiles, personal articles), although processing other
insurance policies is also envisioned.
[0072] The terms "insured," "insured party," "policyholder,"
"customer," "claimant," and "potential claimant" are used
interchangeably herein to refer to a person, party, or entity
(e.g., a business or other organizational entity) that is covered
by the insurance policy, e.g., whose insured article or entity
(e.g., property, life, health, auto, home, business) is covered by
the policy. A "guarantor," as used herein, generally refers to a
person, party or entity that is responsible for payment of the
insurance premiums. The guarantor may or may not be the same party
as the insured, such as in situations when a guarantor has power of
attorney for the insured. An "annuitant," as referred to herein,
generally refers to a person, party or entity that is entitled to
receive benefits from an annuity insurance product offered by the
insuring party. The annuitant may or may not be the same party as
the guarantor.
[0073] Typically, a person or customer (or an agent of the person
or customer) of an insurance provider fills out an application for
an insurance policy. In some cases, the data for an application may
be automatically determined or already associated with a potential
customer. The application may undergo underwriting to assess the
eligibility of the party and/or desired insured article or entity
to be covered by the insurance policy, and, in some cases, to
determine any specific terms or conditions that are to be
associated with the insurance policy, e.g., amount of the premium,
riders or exclusions, waivers, and the like. Upon approval by
underwriting, acceptance of the applicant to the terms or
conditions, and payment of the initial premium, the insurance
policy may be in-force, (i.e., the policyholder is enrolled).
[0074] As used herein, the terms "comprises," "comprising,"
"includes," "including," "has," "having" or any other variation
thereof, are intended to cover a non-exclusive inclusion. For
example, a process, method, article, or apparatus that comprises a
list of elements is not necessarily limited to only those elements
but may include other elements not expressly listed or inherent to
such process, method, article, or apparatus. Further, unless
expressly stated to the contrary, "or" refers to an inclusive or
and not to an exclusive or. For example, a condition A or B is
satisfied by any one of the following: A is true (or present) and B
is false (or not present), A is false (or not present) and B is
true (or present), and both A and B are true (or present).
[0075] 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.
[0076] This detailed description is to be construed as examples and
does not describe every possible embodiment, as describing every
possible embodiment would be impractical, if not impossible. One
could implement numerous alternate embodiments, using either
current technology or technology developed after the filing date of
this application.
* * * * *