US20140257866A1

US20140257866A1 - Systems and methods for processing additional distance units for distance-based insurance policies

Info

Publication number: US20140257866A1
Application number: US14/202,812
Authority: US
Inventors: Christopher E. Gay; Scott T. Christensen; Gregory Hayward; Steven Cielocha; Todd Binion
Original assignee: State Farm Mutual Automobile Insurance Co
Current assignee: State Farm Mutual Automobile Insurance Co
Priority date: 2013-03-10
Filing date: 2014-03-10
Publication date: 2014-09-11
Also published as: US9208525B2; US20140257869A1; US11610270B2; US9105066B2; US9779458B2; US10013719B1; US8799036B1; US9418383B1; US20140257870A1; US10373264B1; US20140257867A1; US20220215479A1; US10387967B1; US10719879B1; US9734537B2; US20140257873A1; US20210312565A1; US12002104B2; US11315189B1; US20140257865A1

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.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

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

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

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.
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.
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

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.
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.
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

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.

FIG. 1 depicts an example environment including components and entities associated with processing distance-based vehicle insurance policies in accordance with some embodiments.

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.

FIGS. 3A-3C depict example interfaces associated with reviewing and selecting additional distance units to purchase in accordance with some embodiments.

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.

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.

FIG. 6 is a block diagram of a processing server in accordance with some embodiments.

DETAILED DESCRIPTION

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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. §112, sixth paragraph.
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.
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.
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.
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.
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).
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).
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.
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.

Claims

What is claimed:

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.