INSURANCE VERTICAL MARKET SPECIALIZATION

Vertical insurance market specialization is provided where policies can be created based on granular information related to actual usage of an object. The information can be received in real time or near real time, and specific market definitions can be created based on the information. Insurance companies can bid on specific market definitions, and an owner of the object can select coverage. In cases of automobile insurance, route information or other sensed parameters (such as driving behavior) can be provided to define an insurance market for a specific driver. Allowing companies to bid on the specific instances allows for increased competition and lower cost than current blanket solutions.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 12/490,033, filed on Jun. 23, 2009, and entitled “INSURANCE VERTICAL MARKET SPECIALIZATION,” which claims priority to U.S. Provisional Application Ser. No. 61/118,400, filed on Nov. 26, 2008, entitled “INSURANCE OPTIMIZER AND REAL TIME ANALYTICS.” The entireties of these applications are incorporated herein by reference.

BACKGROUND

Insurance is typically acquired for many facets of life, including but not limited to automobiles, homes, health, life, disability, shipping goods, personal property, etc., to financially protect assets from unknown or unpredictable occurrences. In many cases, insurance is obtained by receiving quotes from various companies and selecting the most desirable policy considering coverage, price, and other factors. In this regard, insurance companies generate coverage premiums based on a number of factors that represent averaged scenarios regarding the item to be covered. Insurance companies typically have highly proprietary systems that automatically generate premiums using the factors, and each insurance company typically has its own system resulting in varying premiums for different items with respect to different policy holders and desired coverage levels. In this way, it can be difficult for insurance companies to compete with one another, which can also lead to higher premium quotes for all companies.

Insurance premiums are typically fixed in price and billed in monthly, semi-annual, or annual time periods. Premiums can be affected by many policy parameters for which cost is averaged and can be adjusted for a given billing period. For example, with respect to automobile insurance, rates can be set and/or adjusted based on desired coverage level, automobile make, model, and color, automobile features, estimated miles driven each year, zip code of primary automobile location, whether the automobile is garaged, driving history of the policy holder, credit score, etc. In addition, rates can be adjusted at the end of a premium period based on number of claims filed in the primary zip code, weather conditions in the zip code, global factors, and other parameters unrelated to the driver or automobile being covered. With such speculative and broad premium computation, it can be difficult to offer competitive comprehensive insurance policies for certain scenarios, which can hinder the market for insurance.

SUMMARY

The following presents a simplified summary in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview nor is intended to identify key/critical elements or to delineate the scope of the various aspects described herein. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

Vertical market specialization for insurance is provided allowing insurance companies to offer policies in more granular coverage scenarios. For example, an automobile driver can obtain coverage on a per trip or per route basis, based on trip details, one or more environmental details of the car, driving behavior, car equipment, and/or the like. This allows an insurance company to provide a quote based not only on typical factors of driving history, automobile specifications, etc., but also on planned, real time, or near real time aspects of a trip, such as roads traveled, cities visited, amount of time the car is left in a city, average speed, average speed over the speed limit, lane changing, and/or the like, for instance. Where the driver is planning a road-trip much of which is traveled over major highways, premiums can be higher as the cost of potential liability increases due to average speed increasing. Similarly, where the driver is traveling downtown at a low rate of speed, premiums can be lower since the cost of potential liability likely decreases for a given incident. In another example, such factors can be aggregated to provide a more consistent level of coverage over a period of time.

Taking such additional planned or real time (e.g., sensed) factors into account allows companies to specialize in different areas of insurance. For example, continuing the automobile insurance scenario, one insurance company can focus on inner city coverage, such that it provides premiums having lowered cost of potential liability while driving, but increases premiums as the automobile remains unattended in the city (e.g., where the city has high crime rates). Facilitating such specialization allows companies to compete more effectively since more information regarding given coverage scenarios is readily available. In addition, such specialization can apply to other areas of insurance, such as home owner's insurance (e.g., where information regarding activities in the home is available), health insurance, life insurance, etc. Moreover, insurance systems can be coupled to advertising systems such that advertisers can obtain the rich scenario data provided to the insurance system for providing contextual advertisements to one or more users. In one example, users can receive discounted premiums in exchange for providing the rich scenario data.

To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways which can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of an exemplary system that facilitates vertical insurance market specialization.

FIG. 2 illustrates a block diagram of an exemplary system that facilitates generating a market definition from specific parameters and receiving policy quotes.

FIG. 3 illustrates a block diagram of an exemplary system that facilitates creating an insurance market definition from various information sources.

FIG. 4 illustrates a block diagram of an exemplary system that facilitates communicating sensed parameters for market definition.

FIG. 5 illustrates a block diagram of an exemplary system that provides an interface for specifying and/or selecting policy parameters.

FIG. 6 illustrates a block diagram of an exemplary system that facilitates injecting advertisements in vertical insurance market specialization.

FIG. 7 illustrates example interfaces that can be used to effectuate aspects described herein.

FIG. 8 illustrates a block diagram of an exemplary system that facilitates brokering insurance policy selection.

FIG. 9 illustrates a block diagram of an exemplary system that facilitates associating underwriters with insurance market definitions.

FIG. 10 illustrates a block diagram of an exemplary system that facilitates sensing object usage parameters for defining an insurance market.

FIG. 11 illustrates an exemplary flow chart for obtaining policy quotes in a vertical insurance market.

FIG. 12 illustrates an exemplary flow chart for receiving policy rates related to sensed usage parameters of an object to be insured.

FIG. 13 illustrates an exemplary flow chart for providing advertisements in a vertical insurance market system.

FIG. 14 illustrates an exemplary flow chart for sensing object usage parameters and receiving rate quotes based on the parameters.

FIG. 15 illustrates an exemplary flow chart for associating underwriters with an insurance market definition.

FIG. 16 is a schematic block diagram illustrating a sample processing environment.

FIG. 17 is a schematic block diagram of a sample computing environment.

 DETAILED DESCRIPTION

Vertical market specialization for insurance is provided where markets are defined based on granular aspects of coverage and presented to one or more insurance subsystems to obtain quotes for a coverage premium. Such specialization allows insurance companies to compete in more specific areas of insurance coverage, which allows for more accurate premium rates focused on the specific areas or one or more related scenarios. In addition, the granular aspects of coverage can be provided to one or more advertising systems in exchange for further lowered rates, if desired.

According to an example, an insurance market can be defined based on granular information received regarding an item, a related person, use of the item, etc. Based on the market, premium quotes can be obtained from one or more insurance subsystems related to one or more insurance brokers. In addition, rates can be decreased where the granular information can be provided to an advertising system, in one example. In this regard, targeted advertisements can additionally be presented to system related to requesting the insurance coverage. Policies can be automatically selected based on preferences, manually selected using an interface, and/or the like.

Various aspects of the subject disclosure are now described with reference to the annexed drawings, wherein like numerals refer to like or corresponding elements throughout. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the claimed subject matter.

Now turning to the figures, FIG. 1 illustrates a system 100 that facilitates defining specialized markets for insurance and obtaining premium quotes based on a market classification. The system 100 includes a market definition component 102 that can specify an insurance market for a given scenario and an insurance subsystem component 104 that can obtain one or more premium quotes from one or more insurance companies related to the specified insurance market. In one example, the market definition component 102 can determine the insurance market for the given scenario based at least in part on one or more parameters related thereto. In another example, the insurance market can be defined from parameters aggregated or averaged over a period of time. The parameters, as described herein, can relate to usage of an item to be insured and can be provided to the market definition component 102 for a specific instance of use. In addition, the parameters can be sensed from one or more sensing components (not shown) related to using an object. The market definition component 102 can leverage the insurance subsystem component 104 to obtain quotes from insurance companies for writing a policy related to the specific instance of use. Certain insurance companies can specialize in the determined insurance market related to the specific instance of use, in one example, which can be more granular than traditional blanket policies.

According to an example, the market definition component 102 can receive information regarding an automobile insurance policy. Though traditional parameters can be specified, such as automobile type, driving history, zip code, etc., the information received by the market definition component 102 can also relate to details regarding actual use of the automobile for one or more specific instances or averaged over a period of time. Automobiles, as described herein, can include cars, trucks, motorcycles, boats, airplanes, jets, or substantially any vehicle that travels measurable distances. For example, the information can include planned or real time route information, such as whether the automobile is being or will be primarily driven on a highway for a specific period of time. In one example, an insurance company can specialize in road trips to major cities. Thus, the information provided to the market definition component 102 can include a road trip route and/or a length of time away. In this example, the market definition component 102 can define an insurance market for the road trip. The definition can be as granular as desired, such as merely a road trip, a 500+ mile road trip, a road trip to a certain city, a week-long road trip, etc. Once defined, the market definition component 102 can communicate with the insurance subsystem component 104 to generate insurance quotes for the road trip. In another example, where the parameters are aggregated or averaged, the market definition component 102 can create a market for drivers that take frequent road trips and/or drive mostly highway miles.

Similarly, the market definition component 102 can receive information regarding daily driving, which can be specified by a driver and/or obtained from in-automobile systems such as GPS, driving behavior systems, and/or the like. Thus, for example, the market definition component 102 can specify a market for a daily driver that drives 15 miles, primarily in the city, in the AM and PM, Monday through Friday, and often speeds in the morning based at least in part on receiving information from an in-automobile system regarding routes traveled Monday through Friday, time of the traveled route, average speed or speed at different points in the route, and/or the like. Using such information available in many automobiles today can allow insurance companies to provide more specific coverage tailored to given scenarios or habits. This additionally facilitates specialization in market niches, such as primarily city daily driving, road trips, fleet delivery automobiles, etc., providing competition in the markets, and thus a likely decrease in cost for consumers. In addition, where insurance is obtained on a usage basis (e.g., per route), markets can be defined solely for a road trip or daily city driving, such that policies can be reselected when a driver modifies typical driving over a period of time.

In addition, real time information about the automobile itself can be provided to the market definition component 102, such as specifications, equipment, remaining gasoline, tire pressure, oil life, brake life, odometer reading, engine temperature, noise-level inside the car, etc. For example, the market definition component 102 can receive a brake life and odometer reading, from which it can infer a braking level of the driver; such information can also come from a driving behavior system. The market definition component 102 can generate a market definition based on this factor, and an insurance company can specialize, for example, in drivers that are heavy on the brakes. Not only does this allow competition in insurance prices for such drivers, but it allows other companies to specialize in drivers that are not so heavy on the brakes without having to take liability of drivers that are heavy on the brakes into account when quoting a policy, as necessary in current blanket models.

The subject innovation relates to providing a vertical market for insurance coverage where rates can vary based on many aspects of a driver. The aspects can be real-time or forthcoming aspects, such as a currently traveled or planned route. Thus, where the driver is going to grocery store down the street, coverage for the errand can be minimal as compared to a weekend road trip. Various factors can be considered to account for the rate, such as roads traveled currently or on the route, aspects of the road including speed limit, known hazards (potholes, distractions, billboards, etc.), the vehicle type, driving safety history of the driver for the occupied car, time of day (rush hour), if there are others in the car (e.g., by measuring sound and/or weight on the seat—like with seatbelt detectors), other sound issues related to the car (such as vibrations that can indicate the car needs service, such as an oil change, or a brake replacement squeal), and/or the like. Even accident statistic data can be considered (e.g., frequency of accidents along the current or chosen route). Additionally, biofeedback data can be considered, such as the driver's blood pressure, pulse rate (indicating if the driver is alert or on edge, in one example, or has been at various points in the day, etc.), weight, and/or the like. Moreover, companies can compete for coverage based on one or more of the aspects. In one example, companies can specialize in coverage for given aspects, such as a provider that specializes in long trips, certain types of vehicles, safe or reckless drivers, drivers who smoke, etc. In addition, such models can be employed for health insurance (e.g., biofeedback regarding a user), home owners' insurance (whether the doors are locked when no one is present, or whether there is a correlation between driving safety and home safety, for example), and/or the other types of insurance.

Similar historical factors can be provided as well regarding driving behavior, as described in further detail herein. In addition, similar use information can be received from a home (e.g., through a home security system) regarding portions of the day when the home is vacant, doors left open for an extended period of time, etc. Home owner's insurance companies can create similar niche markets allowing the market definition component 102 to define such markets from received parameters (e.g., highly vacant homes, highly occupied homes, etc.) and specify the market to the insurance subsystem component 104 to obtain policy quotes. Moreover, market definitions and subsequent policies can relate to events, a period of time, and/or the like.

Referring to FIG. 2, an example system 200 for defining granular insurance markets for contextual use of an automobile is displayed. System 200 includes a market definition component 102 that discerns an insurance market for locating coverage based on a number of received factors regarding use of an automobile as well as an insurance subsystem component 104 that allows a plurality of insurance companies 208, 210, and 212 to bid on a policy for a market definition received from the market definition component 102, as described. The market definition component 102 can comprise a travel information component 202 that receives one or more real time, planned, or averaged parameters related to automobile travel, such as driver information, automobile information, route information, etc., a market determination component 204 that utilizes the parameters to select a market related thereto, and a rate receiving component 206 that obtains one or more rate quotes from the insurance subsystem component 104 based on the provided automobile travel information.

According to an example, the travel information component 202 can receive information related to travel in an automobile. The information, for example, can relate to a driver, the automobile itself, a use of the automobile, and/or the like. The information can be received from various sources, such as a driving behavior component installed in the automobile, which can provide parameters such as current speed, average speed, braking habits, acceleration habits, tailgating habits, and the like, a GPS system, an in-dash selection component, an odometer, a speedometer, a service or maintenance component, a computing device such as a cellular phone, personal digital assistant (PDA), desktop/laptop computer, netbook, etc., and/or the like. In one example, the various computing devices can communicate with the automobile related devices using a communications medium. This can be a wired or wireless medium, such as universal serial bus (USB), Bluetooth, radio frequency identifier (RFID), WiFi, etc. In addition, the information can be real time information, planned information (such as a planned route), averaged information (such as average speed over certain hours on certain days, when travelling certain routes), and/or substantially any information obtainable or discernable from driving behavior components, automobile devices, GPS, and/or the like.

Using the information, the market determination component 204 can select a market for insurance coverage. The market can be selected using an inference or artificial intelligence technology. For example, parameters received from the travel information component 202 can be measured against parameters specified for certain market definitions, and the market determination component 204 can select a best matched market. In addition, the travel information component 202 can infer one or more disparate parameters from the received parameters. For example, based on a speed and location, the travel information component 202 can infer whether the driver is speeding, by how much, and for how long of a time, and can mark a parameter indicating propensity to speed, providing the parameter to the market determination component 204. Substantially limitless markets can be defined by various parameters and granularities thereof, as described previously. For example, the market definitions can additionally relate to specific uses (e.g., coverage for a single road-trip) and/or generalized uses (e.g., primarily highway driving) so long as related information is received from driving behavior components, GPS, or similar devices, relating to automobile travel, as described. The market determination component 204 matches parameters received from the travel information component 202 with one or more market definitions, and the market definition component sends the market definition to the insurance subsystem component 104.

The insurance subsystem component 104 allows insurance companies 208, 210, and 212, as well as other insurance companies (not shown) to specify markets in which to participate. When the insurance subsystem component 104 receives a market definition from the market definition component 102 for a given scenario, it can forward the market definition and related parameters to insurance companies 208, 210, and 212, and/or related underwriters, to receive bids therefrom. In one example, the insurance subsystem component 104 can provide available market descriptions to the market definition component 102 for which insurance companies 208, 210, and 212 have specified coverage. Specifications can be provided by the insurance companies 208, 210, and 212 by explicit definition (e.g., according to a protocol/specification/schema, which can be provided by the insurance subsystem component 104), by selecting options presented by the insurance subsystem component 104 (e.g., using a user interface), and/or the like. In another example, the market definition component 102 can specify available markets to the insurance subsystem component 104 allowing the insurance companies 208, 210, and 212 to indicate association with one or more specified markets. In this example, the insurance companies 208, 210, and 212 can indicate association with a general market definition and bid policies based on specific parameters of an instance of the general market definition. It is to be appreciated, however, that the market definition can be defined anew including the specific parameters in an alternative example, and the insurance companies 208, 210, and 212 can bid on the policy in this regard.

In either case, the market can be defined by parameter values or ranges. Using the values or ranges, the market definition component 102 can determine markets relating to parameters received from the travel information component 202 as the parameters most closely relate to available markets. For example, insurance companies 208 and 210 can specialize in coverage for, among many other broad and/or specific scenarios, business persons working downtown driving primarily in rush hour traffic, and can indicate or select such a market description to/from the insurance subsystem component 104. It is to be appreciated that the insurance companies 208 and 210, insurance subsystem component 104, and/or market definition component can outline the parameters of such a market description (e.g., travel route, speed range, time of day for traveling, etc.). The travel information component 202 can indicate time of driving, average speed, and route of the specific driver, for example, to the market determination component 204. This information can be obtained from driving behavior components, GPS systems, and/or the like, as described.

The market determination component 204 can match the information to the specific market indicated by the insurance subsystem components 104, and can submit the market definition and other parameters (e.g., automobile type, gasoline level history—e.g., whether the user is constantly riding on an almost empty tank—driver information, and/or the like) to the insurance subsystem component 104. The insurance subsystem component 104 can engage insurance companies 208 and 210, who have associated themselves with the general market definition, for obtaining a policy quote specifying the market description and/or other parameters. The insurance companies 208 and 210 can send a quote for the policy to the insurance subsystem component 104, which can forward the quote to the rate receiving component 206. Rate receiving component 206 can render the rates to a selectable display, such that the driver, upon starting the car and/or indicating that he/she is going to work, can receive the rates for the trip and select the desired policy. It is to be appreciated that the driver need not specify a trip to work; rather this can be inferred based on time of day and/or other parameters, in one example. In another example, the rate receiving component 206 can automatically select a rate and related policy based on lowest price, parameters specified by the driver, and/or the like, as described further herein.

Turning now to FIG. 3, an example system 300 is displayed for generating markets for insurance coverage related to specific automobile travel information. System 300 comprises a market definition component 102 that can receive travel information from multiple sources and formulate a market definition from the information, as described, and an insurance subsystem component 104 that can obtain policy quotes based on the market definition. System 300 can additionally comprise a driver information component 302 that provides information related to a driver of an automobile, such as claim or accident history, age, credit score, etc., an automobile information component 304 that provides data available from one or more components of an automobile, and a route information component 306 that provides information related to one or more planned or current routes of an automobile.

In addition, the automobile information component 304 can include a driving behavior component 308 that can monitor mechanical or electrical aspects of an automobile to discern driving habits, such as current or average speed, odometer reading, braking habits, turning habits, lane-changing frequency, accidents, etc., an automobile equipment/specification component 310 that can provide metrics related to the automobile, such as engine size, gas mileage, weight, etc., as well as equipment on the car, including factory standard or optional equipment and after-market items, such as performance enhancers, breathalyzer car starter, etc. The automobile information component 304 can additionally include an automobile service component 312 that can specify service or maintenance information related to the automobile, such as whether an oil change is due or coming up, miles since last oil change, oil level, gas level, air filter flow, and/or other information that can imply a level of care of the driver and/or risk of liability related to service items (e.g., 8,000 miles overdue for an oil change could cause the engine to lock, which can create additional liability—an insurance company can specialize in this market). The automobile information component 304 also includes an automobile environment sensing component 314 that can detect internal or external environmental factors of the automobile, such as interior noise level (as well as noise detection—e.g., voices, radio, and the like), engine noise level or distinct sounds, brake squealing, or other things that can affect ability to drive the automobile, and thus potential liability.

According to an example, the driver information component 302, automobile information component 304, and/or route information component 306 can provide such information, as described, to the travel information component 202. The travel information component 202 can mine the information providing relevant information and/or information discerned from certain parameters to the market determination component 204, as described above. The market determination component 204 can select a relevant market based on the parameters and can send market information to the insurance subsystem component 104. The rate receiving component 206 can obtain a plurality of policy quotes from the insurance subsystem component 104, as described, for subsequent manual or automatic selection thereof.

For example, the automobile equipment/specification component 310 can provide information regarding a breathalyzer car starter to the travel information component 202. The travel information component 202 can forward this information to the market determination component 204, which can select a market related to automobiles with such starters. In one example, this can lower potential liability since the automobile cannot be started by a drunk driver. Insurance companies, as explained above, can specialize in this niche market and offer rates without having to fully consider scenarios where the driver of the automobile is drunk. The insurance subsystem component 104 can locate such companies, as described previously, and receive related policy quotes for provisioning to the rate receiving component 206. Similarly, for example, the automobile information component 304 can communicate with other devices in the automobile (not shown) such as a cellular phone (e.g., via Bluetooth) to determine whether the driver frequently sends text messages, dials phone numbers, etc. while driving—this information can be provided to the travel information component 202 as well for specific market definition, in one example. Similarly, the automobile information component 304 can communicate with a radio to determine whether the driver frequently changes stations, whether the driver changes using the steering wheel controls or controls on the radio, etc.

In another example, the route information component 306 can provide information on a prospective route or location to the travel information component 202. Thus, for example, the driver can specify a road trip route to a given city. The travel information component 202 can forward this information to the market determination component 204, which can select a market related to insuring such road trips and/or extended stays in the destination city. The market determination component 204 can specify the market to the insurance subsystem component 104, which can locate companies that cover the market, as described previously; related policy quotes can be received and sent to the rate receiving component 206 for display or automatic selection, as mentioned above.

As described, the driver information component 302, automobile information component 304, and route information component 306 can provide parameters to the travel information component 202 as related to coverage for a particular route (e.g., these can be planned parameters). The planned parameters, in one example, can be verified during or after the route, and pricing can be accordingly adjusted, for example where parameters stray from those planned. Additionally, parameters can be provided to the travel information component 202 to obtain coverage for a period of time. In this regard, the parameters can relate to historical data, such as driving behavior, average speed, route information regarding whether miles are primarily city or highway, etc.

In yet another example, the parameters can be provided to the travel information component 202 for coverage in a particular area. Thus, when the automobile enters an area (e.g., as determined by the route information component 306 or other GPS system), area coverage can automatically begin, in one example, through a selected insurance company. Similarly, general coverage can begin when leaving the area and/or a driver can be prompted to select another policy upon entering/leaving areas, upon timed expiration of a policy, etc. In another example, as described herein, policies can be automatically selected seamlessly to the user such that the user can specify coverages or related desired parameters for different areas (e.g., via a computing device) for automatic switching while traveling. In this regard, the route information component 306 can provide GPS information to the travel information component 202. The market determination component 204 can receive the GPS coordinates from the travel information component 202 and can select the area market (e.g., a zip code or city) providing the area market to the insurance subsystem component 104 to receive area policy quotes. The rate receiving component 206 can obtain the policy rates and present them for selection or automatically choose one, as described further herein.

Turning to FIG. 4, an example system 400 is displayed that facilitates communicating information acquired from within an automobile for market definition creation. System 400 includes a market definition component 102 that can model an insurance market based on received parameters and communicate the insurance market to an insurance subsystem component 104 to receive policy quotes from various insurance companies. System 400 also includes an automobile information component 304 that collects information from one or more automobile components, as described, such as a driving behavior component, equipment component, service or maintenance component, environment sensing component, and/or the like; in one example, the automobile information component 304 can be one of these components. System 400 additionally includes a computing component 402 that can facilitate communicating information from the automobile information component 304 to the market definition component 102. It is to be appreciated, in one example, that the automobile information component 304 can be equipped to communicate with the market definition component 102, in which case computing component 402 is not needed.

According to an example, the computing component 402 can be a device that can communicate with the automobile information component 304 and market definition component 102 acting as a gateway between the components. In one example, the market definition component 102 can be remotely located such that the computing component 402 can access a network to communicate therewith. For example, the computing component 402 can be a cellular phone or other mobile device that can communicate over a cellular network. Thus, the computing component 402 can receive data from the automobile information component 304, and transmit the data to the market definition component 102 over the cellular network. Similarly, the computing component 402 can be a handheld device that interfaces with a disparate computer (not shown) at a later time, where the disparate computer has network access to transfer automobile information.

In addition, the computing component 402 can be coupled to the automobile information component 304 via wired or wireless technology (e.g., serial interface, WiFi, Bluetooth, etc.), as described. In another example, the automobile information component 304 can be equipped with technology to communicate with the market definition component 102, such as a cellular modem, and/or the like. In this example, the computing component 402 may not be utilized since the automobile information component 304 directly communicates with the market definition component 102.

Referring to FIG. 5, an example system 500 is illustrated that facilitates selecting insurance coverage from a list of rates and/or other information. The system includes a user interface component 502 that presents one or more rates for selection thereof, a market definition component 102 that generates a market for insurance based on a plurality of received parameters, as described, and an insurance subsystem component 104 that receives the generated market and queries insurance companies for market coverage. The user interface component 502 comprises a policy specification component 504 that can be utilized to provide desired policy coverage parameters to the market definition component 102, in one example, a rate receiving component 506 that can obtain a plurality of insurance coverage rates, as well as other details such as policy information, coverage parameters, contracts, etc., a rate display component 508 that renders insurance coverage rates and/or other information, and a rate selection component 510 that facilitates selecting insurance coverage based on the rendered rates and/or other information.

According to an example, the policy specification component 504 can present policy coverage details on the user interface and allow for selection of one or more policies or details. For instance, the policy specification component 504 can render liability coverage limits for disability, damage, etc., options such as rental car coverage, towing, etc. and/or the like. In addition, the policy specification component 504, in an example, can render options related to route type, such as coverage for a road trip, inner-city driving, and/or the like. The driver can select such options to receive specific quotes for the type of route planned, in this example. For instance, the selectable policies or coverage details can be obtained from the market definition component 102 based on indicated specialized coverages from the insurance subsystem component 104.

The market definition component 102 can model an insurance market definition based on parameters from the policy specification component 504 as well as information received from one or more other sources, such as route information, automobile information, driver information, and/or the like, as described above. The market definition component 102 can leverage the insurance subsystem component 104 to obtain policy rate quotes from different insurance companies specializing in the modeled insurance market and can provide the rate quotes to the user interface component 502. For example, the market definition component 102 can collect desired policy parameters, such as comprehensive coverage with high premiums for a road trip, from the policy specification component 504. The market definition component 102 can obtain other information, such as driver claim history, ticket history, speeding propensity, braking style, lane change frequency, and/or other information from driver history, measured automobile metrics, etc., as described, and define a market definition for transmitting to the insurance subsystem component 104, which can receive rates and communicate the rates to the market definition component 102.

The rate receiving component 506 can obtain the policy rate quotes from the market definition component 102, and the rate display component 508 can render policy and/or rate information. In one example, the rate display component 508 can render the policy and/or rate information on a selectable display (e.g., touch screen, a screen navigable by a mouse or other pointing system, etc.). In another example, the rate display component 508 can audibly render the rate and/or policy information to a radio, phone, etc.

The rate selection component 510 can allow a user to select a policy from those presented by the rate display component 508. In one example, selection can occur, as described, via touch screen, pointing device, keypad, etc. Thus, where the rate display component 508 audibly renders rates, for example, over a phone, a user can use a keypad to select a rate for a route or period of time, as described, based on additional rate and/or policy information. This facilitates insurance market specialization by allowing users to select policies based on specific parameters regarding automobile use, as described, which can additionally facilitate increased competition among companies in the insurance market. As described infra, rate selection can be automated as well so that a driver need not select coverage for every route, time period, etc. It is to be appreciated that the user interface component 502 can be fully or partially implemented within an automobile component, such as a GPS navigation system, a computing device, such as a cellular phone, laptop, home computer, etc., coupled or uncoupled to the automobile or one or more components thereof, and/or the like. In this regard, in addition, the user interface component 502, in one example, can interface with a computing component, much like the automobile information component 304 to computing component 402 as described above, to provide policy specifications, receive rates, and/or the like.

Turning to FIG. 6, an example system 600 for implementing advertising in vertical insurance market specialization systems is illustrated. The system 600 includes a market definition component 102 that can create an insurance market based on one or more parameters received from various components, as described, and can leverage an insurance subsystem component 104 to obtain rate quotes from a plurality of insurance companies. The market definition component 102 can comprise a rate receiving component 206 along with other components, as described previously, that can receive rates from the insurance subsystem component 104. The system 600 additionally includes a user interface component 502, which, as described, can provide policy specifications and receive rate quotes from the market definition component 102 based further on the specifications. The user interface component 502 can include an advertisement display component 604 that can render an advertisement (e.g., visually or audibly) to a driver. In addition, system 600 includes an advertising subsystem component 606 that can receive and store advertisements for presentation to a user interface. The advertising subsystem component 606 can comprise an advertisement generation component 608 that provides one or more advertisements randomly, based on context or one or more inferred scenarios, and/or the like.

According to an example, the market definition component 102 can receive parameters from the user interface component 502 or other components relating to desired insurance coverage, route information, automobile information, driver information, and/or the like as described, and can accordingly generate an insurance market definition. The market definition component 102 can provide the market definition to the insurance subsystem component 104 for receiving policy quotes from a plurality of insurance companies. The rate receiving component 206 can receive policy rate quotes from the insurance subsystem component 104, as described. Upon receiving policy rate quotes, the market definition component 102 can determine whether a related driver has chosen to receive advertisements (e.g., in exchange for reduced rates). In this regard, advertising can be used to subsidize portions of insurance policies, and advertisers can receive access to the rich route information, automobile information, driver information, etc., of opted-in drivers.

If a driver has opted-in to receive advertisements, the rate receiving component 206 can apply a discount to the rates received from the insurance subsystem component 104 upon communicating the rates to the user interface component 502, and the market definition component 102 can transmit received travel information to the advertising subsystem component (e.g., route, automobile, and driver information, as described). In addition, the market definition component 102 can engage advertising subsystem component 606 to propagate an advertisement to the user interface component 502. In this regard, the advertisement generation component 608 can select an advertisement for display to the driver. As mentioned, this advertisement can be contextual, in which case the market definition component 102 can provide route, automobile, driver, or other travel information to the advertising subsystem component 606 to facilitate selecting a contextual advertisement. In another example, the advertisement can be random. In either case, the advertisement generation component can provide the advertisement to the user interface component 502 directly, and/or to the market definition component 102 for transmission to the user interface component 502 along with the discounted rates.

Moreover, the user interface component 502 can be the same as the previously described user interface component 502 that allows policy specification and/or rate selection. In addition or alternatively, however, the user interface component 502 can be substantially any user interface component, such as an in-automobile device (e.g., GPS, car stereo, etc.), a computing device (laptop, personal computer, etc.), cellular phone, associated software application (e.g., web-based email, social networking website, or other personalized website, etc.), other device (e.g., digital video recorder, television, etc.), and/or the like. Thus, where a driver opts-in to receive the advertising, the driver receives discount rates along with advertisements rendered to a number of possible devices.

Now referring to FIG. 7, example interfaces 700 and 702 are displayed for specifying desired coverage parameters and subsequently selecting an insurance policy, as described. It is to be appreciated that the interfaces shown are examples of potentially limitless interface layouts or configurations; the examples are provided for explanation of concepts described herein. In addition, as described, the interfaces can be implemented on in-automobile devices, such as a GPS navigation display, computing devices, and/or the like. Interface 700 can relate to specifying desired policy parameters, as described supra, which can be utilized prior to driving. In this regard, the interface 700 can be displayed in the automobile to allow real time or near real time specification of a planned use. In another example, the interface 700 can be displayed at a computer or cellular phone, for example, before entering the automobile. In one example, this can be based on request by the user, based on contextually inferring that the user is about to get in the car (such as by evaluating communications referring to a road trip, map requests, etc., or based on time of day—e.g., inferring that the user is likely going to/from work, etc.).

Interface 700 can comprise a plurality of parameter entries relating to trip type, distance, etc., as shown, as well as desired coverage details. In addition, an advertisement 704 can be displayed if the driver has opted-in to receive advertisements, as described. Upon submitting the parameters, interface 702 can be displayed (on the same or different interface—e.g., parameter specification can occur on a computer and policy selection on a GPS navigation system) based at least in part on aggregating the desired policy settings of interface 700 along with other automobile or driver information, as described. Interface 702 can display the coverage details along with policy quotes 706 received from a market definition component (not shown). Each policy quote can be related to an insurance company and have an associated rate and/or a rating of the company or policy (indicated by the ‘*’), such as a user rating, better business bureau, etc. In addition, one or more advertisements 708 and 710 can be displayed where the driver has opted-in for advertisements to receive lower rates.

Turning now to FIG. 8, an example system 800 for automatically selecting automobile insurance coverage is illustrated. The system 800 includes a market definition component 102 that can compose an insurance market based on one or more received parameters, as described, and insurance subsystem component 104 that receives a market definition and matches a plurality of providers and related quotes to the definition. System 800 additionally includes a broker agent component 802 that can facilitate automated selecting or brokering of insurance coverage. The broker agent component 802 can include a coverage specification component 804 that receives desired coverage parameters related to a driver, an insurance policy receiving component 806 that can obtain one or more policies from market definition component 102, and an insurance selection component 808 that can select an insurance policy based on the coverage specification.

According to an example, the coverage specification component 804 can receive one or more desired coverage parameters (e.g., from an in-automobile system, computing device, and/or the like), as described in previous figures, and can provide the parameters to the market definition component 102. The market definition component 102 can aggregate the policy parameters along with other parameters related to the automobile, driver, or route, as described, and define an insurance market. It is to be appreciated that the coverage parameters need not be specified to the market definition component 102, in one example, and the market definition component 102 can return policies and rates of various coverage based on the automobile, driver, and/or route information. The market definition component 102 can pass market information to the insurance subsystem component 104 and receive rate and policy information from a plurality of insurance companies. The insurance receiving component 806 can receive the policy and rate information from the market definition component 102.

The insurance selection component 808 can choose an insurance policy from the insurance policy receiving component 806 according to one or more of the coverage parameters or other parameters (such as preference for low price over high rating), that can be specified by the driver (e.g., via interface, as described, in one example). Thus, the driver need not select coverage each time. It is to be appreciated that the broker agent component 802 can be employed where a driver indicates that such automatic selection of coverage is desired, in one example. In this example, the driver can, for instance, interrupt the automatic selection in certain instance (e.g., employ automatic selection for general driving, but select manually for a road trip). In addition, the broker agent component 802 can be internal to a user interface and/or executed remotely by a brokerage company. In the latter example, the brokerage company can constantly shop for rates based on automobile, driver, or planned/real time/near real time route information received, as described above, selecting coverage that best fits the driver's desires for coverage.

Referring to FIG. 9, an example system 900 is shown for implementing market specifications that can be underwritten by one or more insurance companies. System 900 includes a market definition component 102 that can provide a market definition to an insurance subsystem component 104 to receive policy and rate information therefrom, as described. The insurance subsystem component 104 can comprise a market definition receiving component 902 that can obtain one or more supported market definitions for soliciting underwriters, an underwriter association component 904 that can specify underwriters for given market definitions, and a policy receiving component 906 that can receive policy information from underwriters for specific market definitions. In an example, the insurance subsystem component 104 can store a number of market definitions 908 and 910 received from the market definition receiving component 902, and the underwriter association component 904 can correlate one or more underwriters 912 and 914 (e.g., insurance companies, or even independent investors) to specific market definitions based on receiving indications for coverage from the underwriters 912 and 914.

According to an example, the market definition receiving component 902 can pre-define market definitions 908 and 910 or specify them in real time as requests for insurance coverage are received at the market definition component 102. Once defined, underwriters 912 and 914 can communicate with the insurance subsystem component 104 to indicate ability to underwrite policies for certain market definitions 908 or 910. The underwriter association component 904 can correlate the underwriters 912 and 914 to market definitions 908 and/or 910.

In one example, market definitions 908 and 910 can be defined by the market definition component 102 and provided to the market definition receiving component 902 for communication to different insurance companies to obtain underwriters. This step can be a pre-configuration step such that the market definitions are generally defined. In this example, once the underwriter association component 904 correlates underwriters 912 and 914 to the general market definition 908, the market definition component 102 can define an instance of the market definition 908 for a specific driver allowing the underwriters 912 and 914 to bid on the specific policy. The policy receiving component 906 can receive policy information and rates and forward to the market definition component 102.

In another example, market definition can happen in real time such that the market definition component 102 receives automobile, driver, and route information in real time and defines a brand new market definition specific to the driver's exact parameters. The market definition component 102 can provide the specific market definition to the market definition receiving component 902. Underwriters 912 and 914 can bid on the policy based on the specific parameters, and the policy receiving component 906 can obtain policy information and rates providing such to the market definition component 102. The pre-configuration example above can be efficient, since underwriters 912 and 914 are pre-defined for the general market definition and the insurance subsystem component 104 can directly engage the underwriters 912 and 914 for the specific instance, whereas the latter example can be more of a broadcast scenario where the underwriters 912 and 914 seek out the market definition, for instance, and transmit policy information to the policy receiving component 906.

Turning to FIG. 10, an example system 1000 is illustrated that facilitates defining specialized vertical insurance market for substantially any type of insurance. In this example, system 1000 comprises a market definition component 102 that can receive information related to an object, usage thereof, and/or an owner thereof, and can define a market based on the parameters, as described. An insurance subsystem component 104 is also provided that can receive the market definition and solicit policy quotes from a variety of insurance companies. In addition, system 1000 comprises a usage sensing component 1002 that can sense usage of an object to be covered by insurance. In one example, the usage sensing component can be a home security system that can aggregate information related to home occupancy.

In one example, the usage sensing component 1002, where a home security system, can determine during which hours a home is occupied and/or by how many people (or animals). This information can be utilized by the market definition component 102 to define a more granular policy (e.g., a home that is occupied most of the day and night as opposed to a home with a working family that is gone most of the day). This information can greatly affect rates, and defining markets in this way, as described, allows insurance companies to specialize in certain policies and compete, as opposed to current blanket policies.

In addition, for example, the usage component 1002 can communicate with one or more audible environmental sensing components that can detect barking dogs inside the home, lawn mower usage (e.g., a lawn mowed once a week renders a more occupied-looking home than once every two weeks), neighborhood noise (e.g., people walking around and during which hours) or substantially any noise or activity that can be sensed. This information can be provided to the market definition component 102 as well for rich information concerning the home to be covered, which can affect rates. The usage sensing component 1002 can additionally be a driving behavior component or other automobile information component, as described above. In addition, the usage sensing component 1002 can relate to many types of insurance, including property, life, health, and other types of insurance, and can sense how an object to be covered is being utilized to provide more specific coverage (and thus likely lowered rates, as described herein). In addition, advertisement can be provided, as specified above, in exchange for lower rates, as described. The advertisers, in turn, receive access to the sensed information.

The aforementioned systems, architectures and the like have been described with respect to interaction between several components. It should be appreciated that such systems and components can include those components or sub-components specified therein, some of the specified components or sub-components, and/or additional components. Sub-components could also be implemented as components communicatively coupled to other components rather than included within parent components. Further yet, one or more components and/or sub-components may be combined into a single component to provide aggregate functionality. Communication between systems, components and/or sub-components can be accomplished in accordance with either a push and/or pull model. The components may also interact with one or more other components not specifically described herein for the sake of brevity, but known by those of skill in the art.

Furthermore, as will be appreciated, various portions of the disclosed systems and methods may include or consist of artificial intelligence, machine learning, or knowledge or rule based components, sub-components, processes, means, methodologies, or mechanisms (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines, classifiers . . . ), or other inference technologies. Such components, inter alia, can automate certain mechanisms or processes performed thereby to make portions of the systems and methods more adaptive as well as efficient and intelligent, for instance by inferring actions based on contextual information. By way of example and not limitation, such mechanism can be employed with respect to generation of materialized views and the like.

In view of the exemplary systems described supra, methodologies that may be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flow charts of FIGS. 11-15. While for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood and appreciated that the claimed subject matter is not limited by the order of the blocks, as some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Moreover, not all illustrated blocks may be required to implement the methodologies described hereinafter.

FIG. 11 illustrates an example methodology 1100 for obtaining insurance policy quotes based at least in part on specifying a market definition. At 1102, parameters related to an automobile route can be received. The parameters, for example, can relate to a planned or real time route, as described, such that aspects of the route can be used to determine cost of insurance coverage. An insurance market definition can be defined based at least in part on the route at 1104. Thus, for example, a definition can be chosen from a list of possible definitions based on one or more of the parameters and/or tuned in view of the parameters. In another example, the market definition can be created anew with the specific parameters. At 1106, the market definition can be provided to one or more insurance companies. This can be through another entity, such as an insurance subsystem, as described. At 1108, policy information and rates can be received for the market definition from the one or more insurance companies. Thus, for example, the rates and policies can be based on the routes. As described, the rates and policies can be based on additional factors, such as parameters related to a driver or automobile, for example.

FIG. 12 illustrates an example methodology 1200 for obtaining insurance policy quotes based at least in part on specifying a market definition. At 1202, sensed parameters related to an object can be received. The parameters, for example, can relate to various objects, such as automatically sensed driving behavior as related to an automobile or driver, automatically sensed or received home security parameters related to a home, etc., as described. An insurance market definition can be defined based at least in part on the sensed parameters at 1204. Thus, for example, a definition can be chosen from a list of possible definitions based on one or more of the parameters and/or tuned in view of the parameters. At 1206, the market definition can be provided to one or more insurance companies. This can be through another entity, such as an insurance subsystem, as described. At 1208, policy information and rates can be received for the market definition from the one or more insurance companies. Thus, for example, the rates and policies can be based on the sensed parameters.

FIG. 13 illustrates an example methodology 1300 for providing advertising in a vertical insurance market system. At 1302, a plurality of policies and rates related to route, automobile, and/or driver information can be received. As described, the policies can relate to a generated market definition specific to the route, automobile, and/or driver information. At 1304, rates can be discounted based on determining a related driver has opted-in to receive advertisements. Thus, for example, rates can be at least partially subsidized by an advertiser in exchange for route, automobile, and/or driver information, as described. A contextual advertisement can be received from an advertiser based on providing the route, automobile, and/or driver information at 1306. It is to be appreciated that the advertiser can utilize this information to generate an advertisement and for subsequent mining, for example. At 1308, discounted rates, policy information, and the contextual advertisement can be provided to an interface (e.g., for rendering to a driver).

FIG. 14 illustrates an example methodology 1400 for generally receiving insurance policies based on sensed object parameters. At 1402, one or more usage parameters related to an object can be sensed. As described, this can relate to driving behavior, service needs of an automobile, environmental factors, home security system parameters, or substantially any parameters related to an object that can be sensed for more specifically defining an insurance policy. At 1404, the usage parameters can be provided to an insurance subsystem. As described, the subsystem can collaborate with insurance carriers to associate underwriters with general and/or specific market definitions. A plurality of insurance policies related to the usage parameters can be received at 1406, and at 1408, an insurance policy can be selected to cover usage of the object. The policy can be selected manually or automatically. In addition, the policy can relate to a usage instance or event, a period of time, and/or the like, as described.

FIG. 15 illustrates an example methodology 1500 for correlating one or more insurance underwriters with general or specific market definitions. At 1502, a market definition related to a planned route can be received. As described, the route can be explicitly identified and/or inferred based on previous routes, time of day, etc. In addition, the route can be at varying levels of specificity (e.g., a precise route, a city route, a mostly highway route, and/or the like) such that a market definition can be created for varying levels of specificity. At 1504, one or more automobile insurance underwriters can be associated with the market definition. Thus, where the route is general, the underwriters can be associated for future solicitation related to routes falling in the general category. Where more specific, the associated underwriters can actually bid on the policy, as described herein. At 1506, policy and rate information can be received from the automobile insurance underwriters for an instance of the market definition. Thus, rates can be quoted based on the planned route, as described.

As used herein, the terms “component,” “system” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an instance, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computer and the computer can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

The word “exemplary” is used herein to mean serving as an example, instance or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Furthermore, examples are provided solely for purposes of clarity and understanding and are not meant to limit the subject innovation or relevant portion thereof in any manner. It is to be appreciated that a myriad of additional or alternate examples could have been presented, but have been omitted for purposes of brevity.

Furthermore, all or portions of the subject innovation may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed innovation. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device or media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick, key drive . . . ). Additionally it should be appreciated that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a local area network (LAN). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.

In order to provide a context for the various aspects of the disclosed subject matter, FIGS. 16 and 17 as well as the following discussion are intended to provide a brief, general description of a suitable environment in which the various aspects of the disclosed subject matter may be implemented. While the subject matter has been described above in the general context of computer-executable instructions of a program that runs on one or more computers, those skilled in the art will recognize that the subject innovation also may be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks and/or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the systems/methods may be practiced with other computer system configurations, including single-processor, multiprocessor or multi-core processor computer systems, mini-computing devices, mainframe computers, as well as personal computers, handheld computing devices (e.g., personal digital assistant (PDA), phone, watch . . . ), microprocessor-based or programmable consumer or industrial electronics, and the like. The illustrated aspects may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all aspects of the claimed subject matter can be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

With reference to FIG. 16, an exemplary environment 1600 for implementing various aspects disclosed herein includes a computer 1612 (e.g., desktop, laptop, server, hand held, programmable consumer or industrial electronics . . . ). The computer 1612 includes a processing unit 1614, a system memory 1616 and a system bus 1618. The system bus 1618 couples system components including, but not limited to, the system memory 1616 to the processing unit 1614. The processing unit 1614 can be any of various available microprocessors. It is to be appreciated that dual microprocessors, multi-core and other multiprocessor architectures can be employed as the processing unit 1614.

The system memory 1616 includes volatile and nonvolatile memory. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1612, such as during start-up, is stored in nonvolatile memory. By way of illustration, and not limitation, nonvolatile memory can include read only memory (ROM). Volatile memory includes random access memory (RAM), which can act as external cache memory to facilitate processing.

Computer 1612 also includes removable/non-removable, volatile/nonvolatile computer storage media. FIG. 16 illustrates, for example, mass storage 1624. Mass storage 1624 includes, but is not limited to, devices like a magnetic or optical disk drive, floppy disk drive, flash memory or memory stick. In addition, mass storage 1624 can include storage media separately or in combination with other storage media.

FIG. 16 provides software application(s) 1628 that act as an intermediary between users and/or other computers and the basic computer resources described in suitable operating environment 1600. Such software application(s) 1628 include one or both of system and application software. System software can include an operating system, which can be stored on mass storage 1624, that acts to control and allocate resources of the computer system 1612. Application software takes advantage of the management of resources by system software through program modules and data stored on either or both of system memory 1616 and mass storage 1624.

The computer 1612 also includes one or more interface components 1626 that are communicatively coupled to the bus 1618 and facilitate interaction with the computer 1612. By way of example, the interface component 1626 can be a port (e.g., serial, parallel, PCMCIA, USB, FireWire . . . ) or an interface card (e.g., sound, video, network . . . ) or the like. The interface component 1626 can receive input and provide output (wired or wirelessly). For instance, input can be received from devices including but not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, camera, other computer and the like. Output can also be supplied by the computer 1612 to output device(s) via interface component 1626. Output devices can include displays (e.g., CRT, LCD, plasma . . . ), speakers, printers and other computers, among other things.

According to an example, the processing unit(s) 1614 can comprise or receive instructions related to creating a market definition, receiving travel information, communicating with an insurance subsystem, etc., for example. It is to be appreciated that the system memory 1616 can additionally or alternatively house such instructions and the processing unit(s) 1614 can be utilized to process the instructions. Moreover, the system memory 1616 can retain and/or the processing unit(s) 1614 can comprise instructions to effectuate updating of the directory objects to ensure replication with one or more additional operating environments, for example.

FIG. 17 is a schematic block diagram of a sample-computing environment 1700 with which the subject innovation can interact. The system 1700 includes one or more client(s) 1710. The client(s) 1710 can be hardware and/or software (e.g., threads, processes, computing devices). The system 1700 also includes one or more server(s) 1730. Thus, system 1700 can correspond to a two-tier client server model or a multi-tier model (e.g., client, middle tier server, data server), amongst other models. The server(s) 1730 can also be hardware and/or software (e.g., threads, processes, computing devices). The servers 1730 can house threads to perform transformations by employing the aspects of the subject innovation, for example. One possible communication between a client 1710 and a server 1730 may be in the form of a data packet transmitted between two or more computer processes.

The system 1700 includes a communication framework 1750 that can be employed to facilitate communications between the client(s) 1710 and the server(s) 1730. Here, the client(s) 1710 can correspond to program application components and the server(s) 1730 can provide the functionality of the interface and optionally the storage system, as previously described. The client(s) 1710 are operatively connected to one or more client data store(s) 1760 that can be employed to store information local to the client(s) 1710. Similarly, the server(s) 1730 are operatively connected to one or more server data store(s) 1740 that can be employed to store information local to the servers 1730.

By way of example, one or more clients 1710 can define an insurance market definition and transmit the definition to the server(s) 1730 via communication framework 1750. The server(s) 1730 can leverage the server data store(s) 1740 to determine parameters related to the market definition. The server(s) 1730 can obtain insurance rate quotes and transmit such back to the client(s) 1710 via communication framework 1750. The client(s) 1710, in one example, can store quotes (and/or market definition specifications) in the client data store(s) 1760, for example.

What has been described above includes examples of aspects of the claimed subject matter. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the disclosed subject matter are possible. Accordingly, the disclosed subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the terms “includes,” “has” or “having” or variations in form thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.

Claims

1. A system for facilitating vertical market specialization for automobile insurance, comprising:

a processor that executes or facilitates execution of the following computer executable components stored in memory: a travel information component that receives real time parameters regarding driver information, automobile behavior, automobile operational condition, and route of an automobile, wherein the driver information comprises biometric feedback information collected in real-time from the driver; and a rate receiving component that obtains in real-time one or more insurance policy premium quotes from a plurality of insurance companies based at least in part on the parameters received from the travel information component.

2. The system of claim 1, wherein the driver biometric feedback information comprises at least one of: blood pressure, pulse rate, or weight.

3. The system of claim 1, the parameters related to the route of the automobile correspond to one or more routes previously traveled by the automobile.

4. The system of claim 3, the travel information component infers a current route of the automobile based at least in part on the parameters.

5. The system of claim 1, the travel information component further receives one or more parameters related to driving behavior of a driver of the automobile.

6. The system of claim 1, the travel information component further receives one or more parameters related to audible noise level in the automobile.

7. The system of claim 1, further comprising an advertising subsystem component that communicates with a plurality of advertisers to receive one or more advertisements for presentation and receives the parameters related to the route.

8. The system of claim 7, the advertising subsystem component comprises an advertisement generation component that presents an advertisement to a user interface based at least in part on the route.

9. The system of claim 8, the rate receiving component applies a discount to the one or more insurance policy premium quotes from the plurality of insurance companies based at least in part on the advertisement and renders the one or more insurance policy premium quotes to the user interface for selection thereof.

10. A method that facilitates obtaining vertical market insurance coverage information, comprising:

employing a processor to execute computer executable instructions stored in memory to perform the following acts: obtaining information regarding a route of an automobile; defining an insurance market definition based at least in part on the route; and providing the insurance market definition to one or more insurance companies receiving real time parameters regarding driver information, automobile behavior, automobile operational condition, and route of an automobile, wherein the driver information comprises biometric feedback information collected in real-time from a driver; and receiving in real-time one or more insurance policy premium quotes from the one or more insurance companies based at least in part on the received real time parameters.

11. The method of claim 10, further comprising receiving information and rates related to one or more insurance policies corresponding to the insurance market definition.

12. The method of claim 11, further comprising:

receiving an advertisement related to the information regarding the route;
presenting the advertisement over a user interface; and
discounting the rates related to the one or more insurance policies based at least in part on providing the advertisement.

13. The method of claim 10, further comprising receiving the information regarding the route from a user interface.

14. The method of claim 13, the user interface is equipped within the automobile.

15. The method of claim 10, the information regarding the route corresponds to one or more historical tracked routes of the automobile.

16. The method of claim 15, further comprising inferring a current route of the automobile based at least in part on the one or more historical tracked routes, defining the insurance market is based at least in part on the current route.

17. The method of claim 10, further comprising receiving information related to driving behavior obtained from the automobile, defining the insurance market is further based at least in part on the information related to driving behavior.

18. A system for receiving insurance rates according to a vertical market definition, comprising:

means for receiving one or more parameters related to a route of an automobile;
means for generating an insurance market definition based at least in part on the one or more parameters related to the route of the automobile; and
means for sending the insurance market definition to a plurality of insurance companies.

19. The system of claim 18, further comprising means for receiving one or more insurance policy premium quotes from the plurality of insurance companies based at least in part on the one or more parameters related to the route of the automobile.

20. The system of claim 18, the means for receiving the one or more parameters related to the route receives the one or more parameters over a user interface installed in the automobile.

Patent History
Publication number: 20150339780
Type: Application
Filed: Aug 3, 2015
Publication Date: Nov 26, 2015
Applicant: GREAT LAKES INCUBATOR, LLC (Beachwood, OH)
Inventors: Fred Collopy (Cleveland Heights, OH), Craig Allen Nard (Shaker Heights, OH), Himanshu S. Amin (Solon, OH), Gregory Turocy (Moreland Hills, OH), Seyed Vahid Sharifi Takieh (Broadview Heights, OH), Ronald Charles Krosky (Lakewood, OH), David Noonan (Webster Groves, MO), Gustavo Arnaldo Narvaez (Solon, OH), Brian Asquith (Cleveland Heights, OH)
Application Number: 14/816,725
Classifications
International Classification: G06Q 40/08 (20060101); G06Q 30/02 (20060101);