SYSTEMS AND METHODS FOR PROCESSING VEHICLE INSURANCE BASED ON ACUITY TESTING PERFORMANCE

Abstract

Methods and systems for administering acuity assessments to customers who request vehicle insurance policies, and offering insurance policies based on customers' performances on the acuity assessments. In aspects, the vehicle insurance policies can cover various uses of the vehicle, where the policies may be distance- or time-based. The customer requests a vehicle insurance policy and an insurance provider provides a relevant acuity assessment to the customer for completion. The customer performs the acuity assessment and sends corresponding results, and the insurance provider determines the customer's performance. Based at least in part on the customer's performance, the insurance provider generates an insurance quote, which the customer may purchase.

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 systems and methods for offering vehicle insurance policies and, more particularly, to platforms and techniques for rating, underwriting, and processing insurance policy offers based at least in part on performances of customers on acuity tests.

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.

Most vehicle insurance policies are in force for long periods of time (often six months or more). However, there are often instances in which a vehicle operator may only need insurance for a short period of time or for short distances. In these instances, insurance providers are not able to account for the acuity of the vehicle operator in underwriting and pricing an insurance policy. Because insurance providers offer insurance policies based on underwriting risks, there is no way for insurance providers to offer vehicle insurance to these potential customers.

Accordingly, there is an opportunity for systems and methods to assess an underwriting risk of a potential customer for vehicle insurance. In particular, there is an opportunity for systems and methods to administer acuity assessments associated with requests for vehicle insurance policies covering various uses of vehicles.

SUMMARY

In an embodiment, a computer-implemented method of offering vehicle insurance is provided. The method includes receiving, from a customer associated with a vehicle, a request for a vehicle insurance policy covering use of the vehicle, and providing an acuity assessment to the customer for completion by the customer. The method further includes receiving, from the customer associated with the vehicle, acuity data resulting from the customer completing the acuity assessment, generating a quote for the vehicle insurance policy based at least in part on the acuity data, and providing the quote for the vehicle insurance policy to the customer.

In another embodiment, a system for offering vehicle insurance 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 receive, from a customer associated with a vehicle via the communication module, a request for a vehicle insurance policy covering use of the vehicle, and provide, to the customer via the communication module, an acuity assessment for completion by the customer. The processor is further configured to execute the non-transitory computer executable instructions to cause the processor to receive, from the customer associated with the vehicle via the communication module, acuity data resulting from the customer completing the acuity assessment, generate a quote for the vehicle insurance policy based at least in part on the acuity data, and provide, to the customer via the communication module, the quote for the vehicle insurance policy.

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 administering acuity assessments and processing vehicle insurance in accordance with some embodiments.

FIG. 2 depicts an example diagram associated with administering acuity assessments and processing vehicle insurance in accordance with some embodiments.

FIGS. 3A and 3B depict example interfaces associated with an example acuity assessment in accordance with some embodiments.

FIGS. 4A and 4B depict example interfaces associated with an additional example acuity assessment in accordance with some embodiments.

FIGS. 5A and 5B depict example interfaces associated with purchasing an insurance policy in accordance with some embodiments.

FIG. 6 depicts a flow diagram associated with administering acuity assessments and processing vehicle insurance in accordance with some embodiments.

FIG. 7 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. According to certain aspects, a vehicle operator (i.e., customer or potential customer) may, at a given time, not be covered under an associated vehicle insurance policy. The vehicle operator may find himself or herself in a situation or environment in which vehicle insurance is desired or necessary, especially in some short-term usage situations. In normal situations, the vehicle operator does not have the ability to purchase such vehicle insurance because an insurance provider may not have the requisite resources to quickly assess or ascertain an underwriting risk of insuring the vehicle operator.

According to present embodiments, the vehicle operator can use an electronic device to communicate with an insurance provider to facilitate purchase of a vehicle insurance policy. In particular, the vehicle operator may use the electronic device to request a vehicle insurance policy, for example a policy that is related to a short-term use of the vehicle (e.g., a certain amount of miles or a certain time period). To gauge an underwriting risk of the vehicle operator, the insurance provider may identify a relevant acuity assessment, such as an acuity assessment designed to measure or assess the vehicle operator's vision (normal or peripheral), reaction time or other motor coordination, recitation ability, color blindness, depth perception, dual judgment, or other abilities. The insurance provider communicates the acuity assessment to the electronic device, and the vehicle operator uses the electronic device to complete the acuity assessment and send results to the insurance provider. Based on the results of the acuity assessment, the insurance provider determines a quote for a vehicle insurance policy and communicates the quote to the vehicle operator. According to embodiments, the vehicle operator may purchase the vehicle insurance policy using the electronic device and, upon purchase, may be deemed insured according to the policy.

The systems and methods therefore enable customers to effectively and efficiently purchase vehicle insurance policies in situations in which the customers may need a short-term policy. Further, insurance providers are able to accurately gauge underwriting risks for the customers through administration of acuity assessments.

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.

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.

Accordingly, 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, as well as damages by the insured for which the insured is liable, which are caused by covered perils, acts or events as specified by the language of the insurance policy. The payments from the insured to the insurer 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).

FIG. 1 depicts an example environment 100 associated with administering acuity tests and processing vehicle insurance based on results the acuity tests. 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 (“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. According to embodiments, the electronic device 106 may be associated with the vehicle operator, whereby the vehicle operator may have one or more insured vehicles. Further, in some embodiments, the electronic device 106 may be associated with multiple drivers of the same vehicle 105.

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

The vehicle operator may use the electronic device 106 to send a request to the insurance provider 110 for options or quotes for various insurance policies available for the vehicle 105. In particular, the desired insurance policy may be tailored to a short-term use of the vehicle, whereby the insurance policy may offer coverage for a set distance, a set operating time, a set time frame, or other metrics or parameters. For example, “short-term” use may include distances of up to 10,000 miles or more, operating times of up to 500 hours or more, or time frames of up to 6 months or more. It should be appreciated that the acuity assessment techniques as discussed herein may be applied to other, more conventional vehicle insurance policies.

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 acuity assessment or testing information and data. The processing server 125 may be configured to administer or facilitate the administration of an acuity assessment in response to receiving a request for insurance coverage from the electronic device 106. According to some embodiments, the acuity assessments may be software routines, applications, functions, or the like that are configurable to be executed by the electronic device 106. In other embodiments, the processing server 125 (or a user associated therewith) may facilitate the acuity assessments manually such as through conducting the acuity assessments via a telephone call.

The acuity assessments may be configured to measure or assess certain abilities or conditions of the vehicle operator. In particular, the acuity assessments may measure the vehicle operator's vision (normal or peripheral), reaction time or other motor coordination, recitation ability, color blindness, depth perception, dual judgment, and/or other abilities or conditions. For example, one acuity assessment may require the vehicle operator to answer a series of questions within a certain timeframe. For further example, another acuity assessment may require the vehicle operator to react when a certain shape or character is displayed on the electronic device 106. It should be appreciated that other or alternative acuity assessments are envisioned. In some cases, the processing server 125 may select a default or standard acuity assessment to administer to the vehicle operator. In other cases, the processing server 125 may select a particular acuity assessment based on details of the request received from the electronic device 106.

The processing server 125 may be configured to send one or more acuity assessments to the electronic device 106 via the network 120. The electronic device 106 can be configured to initiate or execute (e.g., via a dedicated application) the received acuity assessment. The vehicle operator can view the acuity assessment on the electronic device 106 and perform the acuity assessment by making selections or performing tasks specified by the acuity assessment. The electronic device 106, accordingly, can receive any associated inputs from the vehicle operator, as well as can record or maintain the inputs or results (generally: the acuity data) of the acuity assessment. Further, the electronic device 106 can send the acuity data to the processing server 125 via the network 120. The processing server 125 can examine the acuity data of the acuity assessment to calculate or determine a performance, result, score, or other metric that indicates how the vehicle operator performed on the acuity assessment. In some embodiments, the electronic device 106 can also calculate or determine a performance, result, score, or other metric of the acuity assessment and send the determined performance to the processing server 125 via the network 120.

According to embodiments, the processing server 125 can examine the performance by the vehicle operator on the acuity assessment to determine whether to insure the vehicle operator and how to insure the vehicle operator. Depending on the performance on the acuity assessment, the processing server 125 may deem certain vehicle operators more risky to insure than other vehicle operators. The processing server 125 may therefore generate a quote for an insurance policy for the vehicle operator, with the terms and price of the insurance policy based on the performance on the acuity assessment. The terms of the insurance policy may vary. For example, the insurance policy may offer coverage for a certain amount of miles, a certain amount of operating time, or a certain period of time; coverage with a minimum deductible of a certain amount (e.g., higher/lower deductibles for riskier/safer drivers); coverage with maximum allowable limits (e.g., lower/higher limits for riskier/safer drivers); or coverage having other metrics or parameters. The terms of the insurance policy may be the same or different from the amount of coverage originally requested by the vehicle operator. For example, if the vehicle operator originally requests insurance coverage for 15 miles, but is located only 5 miles from home (and has a relatively low performance on the acuity assessment), the processing server 125 may offer an insurance policy for a distance of 5 miles.

The electronic device 106 may present the quote for the insurance policy to the vehicle operator, and the vehicle operator may select the quote for purchase of the insurance policy. In some cases, the vehicle operator may request a modification to the quote (e.g., more miles or fewer miles), which the processing server 125 may reject or accept, and which may or may not result in a change in price of the insurance policy. For example, if the vehicle operator requests more mileage than what is specified in the quote, the processing server 125 may offer more insured miles, but for a greater rate. If the vehicle operator selects to purchase an insurance policy, the electronic device 106 and the processing server 125 may facilitate a purchase transaction.

Referring to FIG. 2, illustrated is a signal diagram 200 associated with administering acuity assessments and offering vehicle insurance policies based on results of the acuity assessments. 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).

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 vehicle insurance. It should be appreciated that vehicle/customer device 206 may submit the request via a dedicated application, a website, or other channels. In embodiments, the requested insurance policy may relate to a short-term use of the vehicle (e.g., a certain mileage, operating time, time period, or the like). Further, the request may include a desired amount of coverage (e.g., 100 miles, 3 hours, etc.). Additionally, the request may include various customer information, such as the customer's name, phone number, or other identifying or descriptive information.

In embodiments, the customer may specify a specific amount or range of insurance coverage with the request. For example, the customer may determine that he/she is five (5) miles away from home, and may therefore request insurance coverage for five (5) miles. For further example, the customer may request insurance coverage for a trip that is not to exceed thirty (30) minutes. In certain aspects, the electronic device 106 may also store a home address, work address, or other address associated with the customer and may send any address along with its current location (e.g., GPS coordinates) to the insurance provider 210. Accordingly, the insurance provider 210 can determine a distance between the vehicle/customer device 206 (and therefore the vehicle) and a work address, home address, or other address associated with the customer. In this case, the insurance provider 210 may automatically determine that the customer may want insurance coverage for the determined distance.

The insurance provider 210 may receive the request for vehicle insurance and identify (224) a proper acuity assessment to administer to the customer. The identified acuity assessment may be based on the type or amount of vehicle insurance requested. For example, if the request specifies 5,000 miles of coverage, the insurance provider 210 may identify an intelligence test as a relevant acuity assessment to administer to the customer. For further example, if the request specifies 30 minutes of coverage, the insurance provider 210 may identify a motor coordination test as a relevant acuity assessment to administer to the customer. The insurance provider 210 may provide (226) the acuity assessment to the vehicle/customer device 206 and the customer may use the vehicle/customer device 206 to perform and complete (228) the acuity assessment. In some cases, the vehicle/customer device 206 may locally initiate and execute the acuity assessment, for example via a dedicated application. In other cases, an administrator associated with the insurance provider 210 may communicate with the vehicle/customer device 206 (e.g., via a telephone call) to administer the acuity assessment and obtain results therefrom.

After the customer performs and completes the acuity assessment, the vehicle/customer device 206 may provide (230) the acuity assessment results (generally, the acuity data) to the insurance provider 210. In some embodiments, the vehicle/customer device 206 may calculate a score or other type of performance metric for the performed acuity assessment and provide the performance data to the insurance provider 210. After receiving the acuity assessment results, the insurance provider 210 may analyze (232) the results. In particular, the insurance provider 210 may determine a score or performance metric for the acuity assessment. In some cases, the performance metric may be a general indication of the customer's performance such as “PASS” or “FAIL.” In other cases, the performance metric may be a numeric score or percentage (e.g., three seconds, 79%, etc.). It should be appreciated that various algorithms and techniques for determining the customer's performance on the acuity assessment are envisioned.

The insurance provider 210 may use the assessment results to determine (234) whether to insure the customer. In embodiments, the insurance provider 210 may compare the performance metric to a threshold metric and if the performance metric meets or exceeds the threshold metric, the insurance provider 210 may determine to insure the customer (“YES”) and processing may proceed to (238). Similarly, if the performance metric does not meet the threshold metric, the insurance provider 210 may determine to deny coverage to the customer (“NO”) and processing may proceed to (236) at which the insurance provider 210 notifies the customer via the vehicle/customer device 206 that insurance coverage has been denied. It should be appreciated that other techniques to determine whether to insure the customer are envisioned.

At (238), the insurance provider 210 can generate a quote for a vehicle insurance policy. The terms of the quote may be based on the original request from the vehicle/customer device 206 and/or based on the customer's performance on the acuity assessment. In some cases, the insurance provider 210 may adjust any requested terms for an insurance policy based on the customer's performance on the acuity assessment. For example, if the customer requests to be insured for 50 miles and does well on the acuity assessment (e.g., meets or exceeds a threshold metric), then the quote can offer an insurance policy for 50 (or more) miles. For further example, if the customer requests to be insured for 500 miles and does meet a specific threshold performance on the acuity assessment, then the quote can offer an insurance policy for only 200 miles. The insurance provider 210 may also adjust the cost or price of an insurance policy based on the performance of the acuity assessment. Generally, the better the customer's performance on the acuity assessment, the less cost of the insurance policy (and vice-versa). In embodiments, the insurance provider 210 may identify a default insurance policy (e.g., 100 miles, 1 week, etc.) for the customer and adjust the price of the default insurance policy based on the customer's performance on the acuity assessment.

The insurance provider 210 can provide (240) the insurance quote to the vehicle/customer device 206 and the vehicle/customer device 206 can present the insurance quote to the customer. Although not depicted in FIG. 2, the customer may request a modification to the insurance policy (and may receive a modified quote from the insurance provider 210). Otherwise, the customer can use the vehicle/customer device 206 to select (242) to purchase the insurance policy. The insurance provider 210 and the vehicle/customer device 206 may facilitate (244) a purchase transaction for the insurance policy. It should be appreciated that the insurance provider 210 and the vehicle/customer device 206 may employ any checkout or payment processing technique to facilitate the purchase transaction. In cases in which the insurance policy is distance-based, the insurance policy may include an expiration odometer value that is calculated as the sum of the current odometer reading for the vehicle and the total number of miles (or other distance units) included in the selected insurance policy. In cases in which the insurance policy is time-based, the insurance policy may include an expiration time defined as the insured amount of time added to the current time. The time may correspond to an operating time of the vehicle (e.g., engine on/off time), or a current time metric. Further, it should be appreciated that the insurance amount of time may be spread out over multiple time periods. For example, certain time segments may be used on one day while additional time segments may be used on another day, regardless of the elapsing of the current time. The insurance provider 210 may store or record the associated expiration odometer value or expiration time.

Although the embodiments as described relate to initiating or creating a new insurance policy for a customer, it should be appreciated that the techniques may also be used to update or supplement an existing insurance policy for the customer. In particular, the insurance provider 210 may receive the original request for vehicle insurance from the vehicle/customer device 206 and may locate or retrieve an existing insurance policy associated with the vehicle (or an operator of the vehicle), and generate a quote that may be in addition to or in lieu of the existing insurance policy. The insurance provider 210 may provide the quote to the vehicle/customer device 206 and facilitate any subsequent purchase transaction, as detailed herein. In further embodiments, the insurance provider 210 may manage a renewal of a purchased insurance policy, with the same or modified parameters of the purchased insurance policy. Moreover, the acuity assessment may be provided to a temporary vehicle operator having a connection to an existing customer (e.g., a customer's son or daughter), whereby a supplemental insurance policy for the temporary vehicle operator may be created based on the acuity results of the temporary vehicle operator and may be added to the customer's existing insurance policy.

FIGS. 3A, 3B, 4A, and 4B illustrate example interfaces associated with example acuity assessments. 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.

FIG. 3A illustrates an interface 340 indicating a visual acuity assessment that is configured to measure a user's reaction speed. The interface 340 includes instructions for the user to touch a small shape when the user sees one appear. The interface 340 includes several large shapes that may animate throughout the interface 340, disappear, reappear, or cycle through other visual effects. The interface 340 may further include a timer 341 that can measure the amount of time between when a small shape appears on the interface 340 and when the user selects or touches the small shape on the interface 340.

FIG. 3B illustrates another interface 345 for the same visual acuity assessment after a small shape 343 appears on the interface 345. The interface 345 indicates that the user has touched or selected the small shape 343 (“NICE!”) and the timer 341 indicates an amount of time that elapses between when the small shape 343 appeared and when the user selected the small shape 343 (as shown: 0.90″). In some embodiments, the customer/vehicle device (or an insurance provider) may calculate a score or otherwise the user's general performance based on the timer 341 value. Further, the insurance provider may use the score or performance to decide whether to insure the user, as well as determine terms for one or more associated insurance policies to offer the user.

FIG. 4A illustrates an interface 440 indicating a coordination acuity assessment that is configured to measure a user's hand-eye coordination. The interface 440 includes instructions for the user to draw a line from START to FINISH (e.g., via a touch-sensitive interface of the customer/vehicle device). The interface 440 includes a narrow, zig-zagging path with START on a first end and FINISH on a second end.

FIG. 4B illustrates another interface 445 for the same coordination acuity assessment after the user draws a line 444 from START to FINISH. The interface 445 includes an “okay” selection 443 that, upon selection by the user, transmits data associated with the line 444 (generally, the acuity data) to the insurance provider. In some embodiments, the customer/vehicle device (or an insurance provider) may calculate a score or otherwise the user's general performance based on attributes of the line 444, such as how straight the line 444 is, how many times the line 444 contacts or crosses the borders of the path, how long it took the user to draw the line 444, and/or other metrics. Further, the insurance provider may examine the score or performance to decide whether to insure the user, as well as determine terms for one or more associated insurance policies to offer the user.

FIGS. 5A and 5B illustrate example interfaces associated with offering and purchasing an 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.

FIG. 5A illustrates an interface 540 that presents an insurance quote for review by a user of the vehicle/customer device. The interface 540 includes an indication of how the user performed on an acuity assessment (“YOUR ACUITY ASSESSMENT WENT WELL!”) and details various options for short-term vehicle insurance. According to embodiments, the insurance provider may determine the options for the short-term vehicle insurance based on the performance on the acuity assessment by the user. As illustrated in FIG. 5A, the vehicle insurance options include a mileage-based policy (50 miles of coverage for $15.00) and a time-based policy (2 hours of coverage for $12.00).

The interface 540 enables the user to select one of the options for vehicle insurance (as shown: the mileage-based policy is selected). The interface 540 further includes a “purchase” selection 543, a “modify” selection 542, and a “reject” selection 541. If the user selects the purchase selection 543, the vehicle/customer device may initiate a purchase transaction functionality that enables the user to purchase an insurance policy corresponding to the selected quote/option. The modify selection 542 enables the user to select to modify the quote. In some embodiments, the user may select or request an alternate or additional coverage type, which may or may not require approval by the insurance provider and may or may not result in cost modifications. The reject selection 541 enables the user to select to reject the policy, return to a previous screen, quit the application, or another similar functionality.

FIG. 5B illustrates an interface 545 indicating a success message, whereby the success message indicates that the insurance policy purchase was completed, and also indicates various terms of the insurance policy (as shown: 50 miles of coverage). The interface 545 also includes an “okay” selection 547 that, when selected, may dismiss the interface 545 and/or perform other functionalities.

Referring to FIG. 6, depicted is a block diagram of an example insurance policy purchasing technique 600 that may be facilitated between the insurance provider 110 (and specifically the processing server 125) as depicted in FIG. 1 and a customer associated with a vehicle. The customer may access an electronic device (such as the electronic device 106) to perform an acuity assessment and facilitate the purchase of the insurance policy.

The insurance provider can receive (block 605), from the customer associated with the vehicle, a request for a vehicle insurance policy covering short-term usage of the vehicle. In some embodiments, the request may include a requested distance (e.g., 50 miles, 100 miles, etc.) that the customer desires to be covered by the insurance policy, as well as a current odometer reading of the vehicle. In other embodiments, the request may include a time duration (e.g., 30 minutes, 24 hours, etc.) during which the customer desires to be covered by the insurance policy. The insurance provider can identify a relevant acuity assessment and provide (block 610) the acuity assessment to the customer for completion by the customer. It should be appreciated that various acuity assessments are envisioned such as, for example, visual assessments, audio assessments, verbal assessments, physically interactive assessments, or other assessments.

The insurance provider can receive (block 615), from the customer associated with the vehicle, acuity data resulting from the customer completing the acuity assessment. In embodiments, the acuity data may be raw or compiled data resulting from the customer performing and completing the acuity assessment. The insurance provider can examine (block 620) the acuity data to determine a performance by the customer. The performance may be designated as a numerical metric (e.g., a score, percentage, or the like) or a descriptive metric (e.g., “bad,” “fair,” “good,” etc.).

The insurance provider can determine (block 625) whether to insure the customer based on the performance. In embodiments, the insurance provider may compare the performance to a predetermined threshold to determine if the performance meets or exceeds the predetermined threshold. If the insurance provider determines to not insure the customer (“NO”), processing can end or proceed to any other functionality. If the insurance provider determines to insure the customer (“YES”), processing can proceed to block 630 at which the insurance provider can generate a quote for the vehicle insurance policy based at least in part on the performance by the customer. It should be appreciated that the insurance provider may generate the quote based on other factors such as limits, deductibles, territories, type of vehicle, and/or others. Generally, the quote can indicate a policy rate and/or an amount of coverage that may be commensurate with the performance by the customer. In some cases, the insurance provider can modify a policy rate for a default short-term vehicle insurance policy based on the performance. In other cases, the insurance provider can modify an amount of coverage for a default short-term vehicle insurance policy based on the performance.

The insurance provider can provide or communicate (block 635) the quote for the vehicle insurance policy to the customer. In particular, the insurance provider may interface with a vehicle- or customer-based device (e.g., via an application installed thereon) to present the quote. The customer may interact with the vehicle- or customer-based device to review the quote and select to purchase the vehicle insurance policy. In some embodiments, the customer may request a modification to the quote, such as an adjustment to a policy rate, an amount of coverage, and/or other parameters. The insurance provider may calculate or determine any modifications according to the modification request. In any event, if the customer selects to purchase the vehicle insurance policy, the insurance provider may receive (block 640) an acceptance of the quote from the customer. The insurance provider can facilitate (block 645) a purchase transaction with the customer for the insurance policy. In some embodiments, the purchase transaction may be facilitated via the vehicle- or customer-based device, or via other communication channels. Responsive to completing the purchase transaction, the insurance policy may be deemed active for the customer.

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

The processing server 725 can include a processor 722 as well as a memory 778. The memory 778 can store an operating system 779 capable of facilitating the functionalities as discussed herein as well as a set of applications 775 (i.e., machine readable instructions). For example, one of the set of applications 775 can be a policy processing application 784 configured to facilitate the offering and purchase of an insurance policy, and another of the set of applications 775 can be an acuity assessment application 790 configured to administer acuity assessments and process results from the acuity assessments. It should be appreciated that other applications are envisioned.

The processor 722 can interface with the memory 778 to execute the operating system 779 and the set of applications 775. According to embodiments, the memory 778 can also include a data record storage 780 that stores location and operating information associated with a plurality of vehicles. The policy processing application 784 may interface with the data record storage 780 to retrieve relevant information that the policy processing application 784 may use to generate insurance policies and terms associated therewith. The memory 778 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 725 can further include a communication module 777 configured to communicate data via one or more networks 720. According to some embodiments, the communication module 777 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 776. For example, the communication module 777 can send, via the network 720, acuity assessments and receive acuity data resulting from assessment performance. The processing server 725 may further include a user interface 781 configured to present information to a user and/or receive inputs from the user. As shown in FIG. 7, the user interface 781 includes a display screen 782 and I/O components 783 (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 725 via the user interface 781 to process insurance policies and/or perform other functions. In some embodiments, the processing server 725 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 722 (e.g., working in connection with the operating system 779) 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.

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 offering vehicle insurance, the method comprising:

receiving, from a customer associated with a vehicle, a request for a vehicle insurance policy covering use of the vehicle;

providing, by one or more processors, an acuity assessment to the customer for completion by the customer;

receiving, from the customer associated with the vehicle, acuity data resulting from the customer completing the acuity assessment;

generating, by one or more processors, a quote for the vehicle insurance policy based at least in part on the acuity data; and

providing the quote for the vehicle insurance policy to the customer.

2. The computer-implemented method of claim 1, wherein receiving the request for the vehicle insurance policy comprises:

receiving, from the customer, a distance desired to be covered by the insurance policy and a current odometer reading of the vehicle.

3. The computer-implemented method of claim 1, wherein generating the quote for the vehicle insurance policy based on the acuity data comprises:

examining the acuity data to determine a performance by the customer on the acuity assessment; and

generating the quote based on the performance by the customer.

4. The computer-implemented method of claim 3, wherein generating the quote based on the performance by the customer comprises:

identifying at least one of an amount of coverage and coverage terms for a default vehicle insurance policy;

adjusting the at least one of the amount of coverage and the coverage terms based on the performance by the customer; and

generating the quote according to the adjusted amount of coverage.

5. The computer-implemented method of claim 3, wherein generating the quote based on the performance by the customer comprises:

identifying a policy rate for a default vehicle insurance policy;

adjusting the policy rate based on the performance by the customer; and

generating the quote according to the adjusted policy rate.

6. The computer-implemented method of claim 3, further comprising:

determining that the performance by the customer meets a threshold value.

7. The computer-implemented method of claim 1, further comprising:

receiving an acceptance of the quote from the customer; and

facilitating a purchase transaction with the customer for the vehicle insurance policy.

8. The computer-implemented method of claim 1, wherein providing the acuity assessment to the customer for completion by the customer comprises:

providing, to the customer, at least one of a visual assessment, an audio assessment, a verbal assessment, and a physically interactive assessment.

9. The computer-implemented method of claim 1, wherein receiving the request for the vehicle insurance policy comprises:

receiving, from the customer, a time duration during which the customer desires to be covered by the insurance policy.

10. The computer-implemented method of claim 1, further comprising:

receiving a request to modify the quote for the vehicle insurance policy;

based on the request to modify the quote, adjusting at least one of a policy rate and an amount of coverage indicated in the quote for the vehicle insurance policy; and

providing the at least one of the adjusted policy rate and the adjusted amount of coverage to the customer.

11. A system for offering vehicle insurance, 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: receive, from a customer associated with a vehicle via the communication module, a request for a vehicle insurance policy covering use of the vehicle, provide, to the customer via the communication module, an acuity assessment for completion by the customer, receive, from the customer associated with the vehicle via the communication module, acuity data resulting from the customer completing the acuity assessment, generate a quote for the vehicle insurance policy based at least in part on the acuity data, and provide, to the customer via the communication module, the quote for the vehicle insurance policy.

12. The system of claim 11, wherein to receive the request for the vehicle insurance policy, the processor is configured to:

receive, from the customer via the communication module, a distance desired to be covered by the insurance policy and a current odometer reading of the vehicle.

13. The system of claim 11, wherein to generate the quote for the vehicle insurance policy based on the acuity data, the processor is configured to:

examine the acuity data to determine a performance by the customer on the acuity assessment, and

generate the quote based on the performance by the customer.

14. The system of claim 13, wherein to generate the quote based on the performance by the customer, the processor is configured to:

identify at least one of an amount of coverage and coverage terms for a default vehicle insurance policy,

adjust the at least one of the amount of coverage and the coverage terms based on the performance by the customer, and

generate the quote according to the adjusted amount of coverage.

15. The system of claim 13, wherein to generate the quote based on the performance by the customer, the processor is configured to:

identify a policy rate for a default vehicle insurance policy,

adjust the policy rate based on the performance by the customer, and

generate the quote according to the adjusted policy rate.

16. The system of claim 13, wherein the processor is further configured to:

determine that the performance by the customer meets a threshold value.

17. The system of claim 11, wherein the processor is further configured to:

receive, from the customer via the communication module, an acceptance of the quote, and

facilitate a purchase transaction with the customer for the vehicle insurance policy.

18. The system of claim 11, wherein to provide the acuity assessment to the customer for completion by the customer, the processor is configured to:

provide, to the customer via the communication module, at least one of a visual assessment, an audio assessment, a verbal assessment, and a physically interactive assessment.

19. The system of claim 11, wherein to receive the request for the vehicle insurance policy, the processor is configured to:

receive, from the customer via the communication module, a time duration during which the customer desires to be covered by the insurance policy.

20. The system of claim 11, wherein the processor is further configured to:

receive, via the communication module, a request to modify the quote for the vehicle insurance policy;

based on the request to modify the quote, adjust at least one of a policy rate and an amount of coverage indicated in the quote for the vehicle insurance policy, and

provide, to the customer via the communication module, at least one of the adjusted policy rate and the adjusted amount of coverage.