SYSTEMS AND METHODS FOR PROCESSING CREDITS FOR DISTANCE-BASED INSURANCE POLICIES

Abstract

Methods and systems for processing credits for customers having distance-based insurance policies for vehicles. According to aspects, a distance-based insurance policy of a vehicle specifies an amount of distance units for insured vehicle travel and has an associated policy term. Upon expiration of the policy term, an insurance provider receives an odometer reading and uses the odometer reading to calculate an amount of unused distance units. The insurance provider may determine one or more types of credit that are based on the amount of unused distance units. The insurance provider may also apply the one or more types of credit to an account of the customer.

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 processing various credits resulting from 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 one (1) month. However, in situations in which a particular customer has unused distance units at the end of the policy term, the particular customer is not appropriately credited or refunded.

Accordingly, there is an opportunity for systems and methods to process credits associated with distance-based vehicle insurance policies. In particular, there is an opportunity for systems and methods to process credits that are commensurate with any unused distance units associated with distance-based vehicle insurance policies.

SUMMARY

In an embodiment, a computer-implemented method of crediting customers having vehicle insurance policies is provided. The method includes facilitating a purchase transaction with a customer for a distance-based insurance policy associated with a vehicle, a coverage provided by the distance-based 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 insurance policy, and (2) expires at a pre-determined time. The method further includes, responsive to the pre-determined time expiring, receiving a subsequent odometer reading of the vehicle and, based on the subsequent odometer reading, determining that the expiration odometer value has not been reached. Moreover, the method includes applying a credit to an account of the customer.

In another embodiment, a system for crediting customers having vehicle insurance policies 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 distance-based 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 insurance policy, and (2) expires at a pre-determined time. The processor is further configured to, responsive to the pre-determined time expiring, receive a subsequent odometer reading of the vehicle and, based on the subsequent odometer reading, determine that the expiration odometer value has not been reached. Moreover, the processor is configured to apply a credit to an account of the customer.

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 credits associated with distance-based vehicle insurance policies in accordance with some embodiments.

FIG. 2 depicts an example diagram associated with processing credits associated with distance-based vehicle insurance policies in accordance with some embodiments.

FIGS. 3A-3D depict example interfaces associated with reviewing and selecting credits associated with distance-based vehicle insurance policies in accordance with some embodiments.

FIG. 4 depicts a flow diagram associated with processing credits associated with distance-based vehicle insurance policies in accordance with some embodiments.

FIG. 5 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 crediting customers having distance-based insurance policies through insurance provider. 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.

Although some customers will meet the distance unit limit during the policy term, there will also be instances in which customers have a balance or remainder of unused distance units upon expiration of the policy term. According to the present embodiments, the systems and methods are configured to process credits or refunds according to the unused distance units. Upon expiration of a policy term for a particular distance-based insurance policy, the insurance provider may query the vehicle or customer for an odometer reading and compare that odometer reading to an expiration odometer value that is calculated when the customer purchases the distance-based insurance policy. If there are unused distance units, then the customer may be due some form of credit or refund. According to aspects, the credit may be in the form of “rollover” distance units, monetary credit or cash, credit with the insurance provider, various discounts or offers, and/or other types of credit.

The systems and methods therefore offer a benefit to customers by rewarding credit that corresponds to what is effectively unused insurance coverage. Accordingly, customers may be incentivized to purchase distance-based vehicle insurance, especially in situations in which the customers may otherwise operate a vehicle without insurance. 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 various types of credits associated with 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 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 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.

According to the present embodiments, the insurance provider 110 is configured to process refunds, credits, or the like (generally: “credits”) for any distance units that are unused as of the end of a policy term for a distance-based insurance policy. The insurance provider 110 is configured to maintain accounts for the vehicle operators, whereby the accounts specify the terms of the distance-based insurance policies. The insurance provider 110 may also determine an appropriate amount of credits and apply the credits to the accounts.

In some cases, the credits may be in the form of “rollover” distance units. For example, if a distance-based insurance policy covers 500 miles and at the end of the policy term there are 40 unused miles, then these 40 unused miles may be deemed as rollover miles and the insurance provider 110 may credit these 40 miles to an account of the corresponding vehicle operator. In other cases, the credits may be in the form of a monetary credit (i.e., cash or cash equivalent), whereby any unused distance units may have an associated value that the insurance provider 110 can use to calculate the monetary credit owed to a vehicle operator. For example, if a vehicle operator has 20 unused miles at the end of the policy term and each unused mile has a cash value of $0.20, then the insurance provider 110 can determine that the vehicle operator is owed $4.00 and can credit an account of the vehicle operator, such as by processing a “refund,” issuing a check or other payment, adding to an account balance, or performing another refund. The credit may also be in other forms, such as a credit with the insurance provider 110, a discount on subsequent insurance products, or other types of credit.

The processing server 125 can be coupled to a database 115 configured to store data associated with vehicle insurance policies. Further, the database 115 may store account data associated with accounts of customers. The processing server 125 may be configured to monitor expiration dates of the distance-based insurance policies, as well as process appropriate refunds or credits according to any unused distance units. In some embodiments, the processing server 125 may also facilitate the purchase of additional or renewal insurance policies for the customers.

Referring to FIG. 2, illustrated is a signal diagram 200 associated with processing credits 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 process credits 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. 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.

At a specified time or date, the policy term of the insurance policy expires, as indicated by 229 in FIG. 2. Upon expiration of the policy term, the insurance provider 210 can request (228) the vehicle/customer device 206 for a subsequent odometer reading, whereby the subsequent odometer reading represents the odometer reading of the vehicle at or near the expiration time/date of the policy term. The vehicle/customer device 206 can provide (230) 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 (232) if any unused distance units remain. 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 is 12,900 miles, then there is a total of 100 unused miles. If the insurance provider 210 determines that there are no distance units remaining (“NO”), the insurance provider 210 can notify (234) the customer of any renewal or repurchase options, and the customer may optionally complete an additional purchase transaction for a subsequent or additional insurance policy.

If the insurance provider 210 determines that there are remaining unused distance units (“YES”), the insurance provider 210 can calculate (236) a value or credit associated with the unused distance units. In some embodiments, the insurance provider 210 may designate any unused distance units as “rollover” distance units (e.g., on a 1-1 basis, 2-1 basis, or other bases) that may be applied towards an additional or subsequent distance-based insurance policy. In other embodiments, the insurance provider 210 may convert any unused distance units into one or more discounts that may be applied to an additional or subsequent insurance policy, or to other products or services. For example, if a policy term ends with 500 unused distance units, then the insurance provider may determine that the 500 unused distance miles are worth a 20% off discount on a subsequent distance-based insurance policy. In further embodiments, the insurance provider 210 may convert any unused distance units into insurance provider 210 credits (i.e., a value accepted as monetary payment by the insurance provider 210) that may be applied to an additional or subsequent insurance policy.

In still further embodiments, the insurance provider 210 may convert any unused distance units into cash or a cash equivalent. In particular, each unused distance unit may have a set or variable cash value, which may be commensurate with the policy rate for the distance-based insurance policy. In some cases, the cash or cash equivalent may be in the form of an investment asset that may be applied to an insurance policy renewal and that may accrue value over time. Accordingly, the customer is able to build equity in the distance-based insurance policy, similar to how cash values accrue in some life insurance policies. In embodiments, the value of this type of investment asset may be more than a calculated cash value for the same amount of unused distance units, in an effort to incentivize the customer to purchase insurance renewals.

In some embodiments, the insurance provider 210 may offer (238) one or more credit options to the customer, for the customer to select a desired type of credit. For example, the insurance provider may offer the customer a cash value, rollover distance units, or a discount, or a combination thereof. The customer may use the vehicle/customer device 206 to select a credit option and provide (240) the selection to the insurance provider 210. The insurance provider 210 can apply (246) the determined or selected type of credit to an account of the customer. For example, the insurance provider 210 can apply rollover distance units to a customer account. For further example, the insurance provider 210 can deposit money into an account of the customer (or physically mail a check to the customer). The insurance provider 210 can also notify (244) the customer of the account credit.

FIGS. 3A-3D illustrate example interfaces associated with processing various types of credits associated with distance-based vehicle insurance policies. 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 of an expiration of a policy term for a distance-based insurance policy. In embodiments, an insurance provider may notify the vehicle/customer device when the policy term lapses, which can cause the vehicle/customer device to display the interface 348. The interface 348 in FIG. 3A enables the customer to enter, via an input box 349, the current odometer reading of the vehicle having the insurance policy. It should be appreciated that the current odometer reading may be identified manually or automatically. The interface 348 may also include a “submit” selection 347 that, upon selection by the customer, causes the vehicle/customer device to transmit the current odometer reading value to the insurance provider. Of course, the insurance provider can determine whether there are unused distance units based on the current odometer reading.

FIG. 3B illustrates an interface 350 that notifies the customer of any unused distance units that remain from the distance-based insurance policy. In particular, the interface 350 indicates that the customer has 252 unused miles, an amount which may be calculated based on the current odometer reading input into 349 and according to the techniques as discussed herein. The interface 350 also indicates an option for reviewing various credit options for the unused miles, which the customer may choose to review (or not review) via a “no” selection 351 or a “yes” selection 352.

FIG. 3C illustrates an interface 355 that presents credit options for the unused distance units. According to embodiments, the insurance provider may calculate the credit options based on the amount of unused distance units (as shown: 252 miles). As shown in FIG. 3C, the credit options include an option for rollover miles, a 10% discount on a renewal insurance policy, $25.00 cash, and $35.00 cash accrual for a renewal policy. The interface 355 enables the customer to select one of the credit options via radio buttons (as shown: the $25.00 cash option 356). Further, the interface 355 includes a “cancel” selection 357 that enables the customer to exit the credit selection processing and a “submit” selection 358 that enables the customer to submit the selected credit option to the insurance provider.

FIG. 3D illustrates an interface 360 that notifies the customer of the status of the selected credit option. As shown in FIG. 3D, the interface 360 informs the customer that $25.00 has been deposited into his or her bank account. The interface 360 also indicates an option for reviewing options to purchase a renewal insurance policy, which the customer may choose to review (or not review) via a “no thanks” selection 361 or a “yes” selection 362.

Referring to FIG. 4, depicted is a block diagram of an example method 400 for crediting a customer having 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 a pre-determined time (i.e., has a specified policy term). 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.

Line 416 of the method 400 represents an expiration of the pre-determined time (i.e., an expiration of the policy term) for the distance-based insurance policy. At block 420, the insurance provider can request a subsequent odometer reading of the vehicle after the pre-determined time expires. 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. 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.

If the insurance provider determines that the expiration odometer value has been reached (“YES”), processing can end or proceed to any other functionality. If the insurance provider determines that the expiration odometer value has not been reached (“NO”), processing can proceed to block 435 at which the insurance provider can calculate a difference in distance between the subsequent odometer reading and the expiration odometer value, where the difference in distance represents the unused distance units.

The insurance provider can next calculate (block 440) a credit based on the difference in distance. In embodiments, the credit may be in the form of a credit amount of distance units (or “rollover” distance units) according to the difference in distance. In other embodiments, the credit may be in the form of a monetary credit (e.g., cash or cash equivalent). In further embodiments, the credit may be in the form of a monetary accrual amount (e.g., a cash accrual policy), whereby the customer may choose whether to receive the monetary value of the credit or have an account (e.g., an investment account) credited with the monetary accrual amount. Moreover, in embodiments, the credit may be in the form of a discount offer, such as a discount offer for a subsequent or further insurance policy term. The insurance provider can apply (block 445) the credit to an account of the customer. In some cases, for example if the credit is a monetary credit, the insurance provider may deposit the monetary credit into a bank account of the customer (or send a check to the customer). Otherwise, the insurance provider can update the account of the customer according to the type of the credit and the value of the credit.

FIG. 5 illustrates a diagram of an example processing server 525 (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 525 can be associated with an insurance provider, as discussed herein.

The processing server 525 can include a processor 522 as well as a memory 578. The memory 578 can store an operating system 579 capable of facilitating the functionalities as discussed herein as well as a set of applications 575 (i.e., machine readable instructions). For example, one of the set of applications 575 can be a policy processing application 584 configured to facilitate the offering and purchase of distance-based insurance policies. It should be appreciated that other applications are envisioned.

The processor 522 can interface with the memory 578 to execute the operating system 579 and the set of applications 575. According to embodiments, the memory 578 can also include customer account information 580 that includes information related to accounts of customers, including insurance policies and credits associated therewith. The policy processing application 584 may interface with the customer account information 580 to retrieve relevant information that the policy processing application 584 may use to process insurance policies and terms associated therewith. The memory 578 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 525 can further include a communication module 577 configured to communicate data via one or more networks 520. According to some embodiments, the communication module 577 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 576. For example, the communication module 577 can send, via the network 520, requests for odometer information and/or credit options and receive relevant data and selections. The processing server 525 may further include a user interface 581 configured to present information to a user and/or receive inputs from the user. As shown in FIG. 5, the user interface 581 includes a display screen 582 and I/O components 583 (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 525 via the user interface 581 to process insurance policies and/or perform other functions. In some embodiments, the processing server 525 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 522 (e.g., working in connection with the operating system 579) 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.

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

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.

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

1. A computer-implemented method of crediting customers having vehicle insurance policies, the method comprising:

facilitating, by a processor, a purchase transaction with a customer for a distance-based insurance policy associated with a vehicle, a coverage provided by the distance-based 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 a pre-determined time;

responsive to the pre-determined time expiring, receiving a subsequent odometer reading of the vehicle;

based on the subsequent odometer reading, determining, by the processor, that the expiration odometer value has not been reached; and

applying a credit to an account of the customer.

2. The computer-implemented method of claim 1, wherein applying the credit to the account of the customer comprises:

calculating a difference in distance between the subsequent odometer reading and the expiration odometer value; and

applying the credit to the account of the customer, the credit based on the difference in distance.

3. The computer-implemented method of claim 2, wherein applying the credit to the account of the customer comprises:

crediting the account of the customer with a credit of distance units according to the different in distance.

4. The computer-implemented method of claim 2, wherein applying the credit to the account of the customer comprises:

calculating a monetary credit based on the difference in distance; and

applying the monetary credit to the account of the customer.

5. The computer-implemented method of claim 2, wherein applying the credit to the account of the customer comprises:

calculating a discount offer based on the difference in distance, the discount offer for use on a future insurance policy term; and

applying the discount offer to the account of the customer.

6. The computer-implemented method of claim 2, wherein applying the credit to the account of the customer comprises:

calculating, based on the difference in distance, (1) a monetary accrual amount and (2) a monetary credit;

providing the customer with an option to select, as a credit, either the monetary accrual amount or the monetary credit;

receiving a selected credit from the customer; and

processing the account of the customer based on the selected credit.

7. The computer-implemented method of claim 6, wherein when the selected credit is the monetary accrual amount, processing the account of the customer based on the selected credit comprises:

crediting an account of the customer with the monetary accrual amount.

8. The computer-implemented method of claim 6, wherein when the selected credit is the monetary credit, processing the account of the customer based on the selected credit comprises:

applying the monetary credit to the account of the customer.

9. The computer-implemented method of claim 1, wherein receiving the subsequent odometer reading of the vehicle comprises:

requesting the customer to provide the subsequent odometer reading; and

receiving the subsequent odometer reading of the vehicle from at least one of an electronic device of the vehicle and an electronic device of the customer.

10. The computer-implemented method of claim 1, wherein receiving the subsequent odometer reading of the vehicle comprises:

responsive to the pre-determined time expiring, automatically requesting the customer to provide the subsequent odometer reading; and

receiving the subsequent odometer reading from the customer.

11. A system for crediting customers having vehicle insurance policies, 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 distance-based 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 a pre-determined time, responsive to the pre-determined time expiring, 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 not been reached, and apply a credit to an account of the customer.

12. The system of claim 11, wherein to apply the credit to the account of the customer, the processor is configured to:

calculate a difference in distance between the subsequent odometer reading and the expiration odometer value, and

apply the credit to the account of the customer, the credit based on the difference in distance.

13. The system of claim 12, wherein to apply the credit to the account of the customer, the processor is configured to:

credit the account of the customer with a credit of distance units according to the different in distance.

14. The system of claim 12, wherein to apply the credit to the account of the customer, the processor is configured to:

calculate a monetary credit based on the difference in distance, and apply the monetary credit to the account of the customer.

15. The system of claim 12, wherein to apply the credit to the account of the customer, the processor is configured to:

calculate a discount offer based on the difference in distance, the discount offer for use on a future insurance policy term, and

apply the discount offer to the account of the customer.

16. The system of claim 12, wherein to apply the credit to the account of the customer, the processor is configured to:

calculate, based on the difference in distance, (1) a monetary accrual amount and (2) a monetary credit,

provide the customer with an option to select, as a credit, either the monetary accrual amount or the monetary credit,

receive a selected credit from the customer via the communication module, and

process the account of the customer based on the selected credit.

17. The system of claim 16, wherein to process the account of the customer when the selected credit is the monetary accrual amount, the processor is configured to:

credit an account of the customer with the monetary accrual amount.

18. The system of claim 16, wherein to process the account of the customer when the selected credit is the monetary credit, the processor is configured to:

apply the monetary credit to the account of the customer.

19. The system of claim 11, wherein to receive the subsequent odometer reading of the vehicle, the processor is configured to:

request the customer to provide the subsequent odometer reading, and

receive, via the communication module, the subsequent odometer reading of the vehicle from at least one of an electronic device of the vehicle and an electronic device of the customer.

20. The system of claim 11, wherein to receive the subsequent odometer reading of the vehicle, the processor is configured to:

responsive to the pre-determined time expiring, automatically request the customer to provide the subsequent odometer reading, and

receive, via the communication module, the subsequent odometer reading from the customer.