Road Segment Safety Rating

[0001] This application is a continuation-in-part of, and claims priority to, co-pending U.S. application Ser. No. 14/100,913, filed Dec. 9, 2013, which is a continuation of U.S. patent application Ser. No. 12/118,021, filed May 9, 2008, issued Dec. 10, 2013 as U.S. Pat. No. 8,606,512, which claims priority to U.S. Provisional Patent Application No. 60/917,169 filed May 10, 2007. All of the aforementioned are incorporated by reference in their entirety herein.

[0002] Aspects of the invention relate generally to risk mitigation. More particularly, aspects of the invention relate to using geographically encoded information to promote and/or reward risk mitigation. Various aspects of the disclosure relate to road segment safety rating systems. More specifically, aspects of the disclosure relate to determining a road segment safety rating based on historical road segment data and/or driving behavior data of an operator of a vehicle, determining whether the road segment safety rating is above a pre-determined threshold, providing alternate road segments to a user, providing insurance incentives to a user based on the road segment safety rating, and/or providing real-time (or near real-time) alerts or warnings to a user about upcoming safety hazards.

[0003] Although insurers may vary insurance premiums based on garaging location (by state, county, etc.), there is a need in the art for enhanced systems and methods to better account for variations in a location-based risk to vehicles and subsequently acting accordingly. For example, some insurers use location-based technology such as GPS (global positioning satellites) to monitor the location of vehicles. Nevertheless, there is a need in the art for a technique for estimating the risk associated with a route using the various aspects disclosed by the present disclosure.

[0004] Often, when operating a vehicle, drivers do not consider safety of a road or route they are taking when making decisions on how to arrive at a destination. Rather, drivers often rely on criteria such as fastest route, shortest distance, etc. to plan a route to a destination. Because the amount of data needed to determine a safety rating for a road can be tremendous, it is often not practical for individuals to evaluate the safety of each road. However, access to this information could be advantageous. Therefore, there is a benefit in the art for an enhanced method and device for calculating a risk for a road segment and using it to, among other things, mitigate risk.

[0005] The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosure. The summary is not an extensive overview of the disclosure. It is neither intended to identify key or critical elements of the disclosure nor to delineate the scope of the disclosure. The following summary merely presents some concepts of the disclosure in a simplified form as a prelude to the description below.

[0006] Aspects of the disclosure relate to methods, computer-readable media, systems and apparatuses for determining a road segment safety rating. In some arrangements, the road segment safety rating may be based on historical data associated with the road segment (e.g., accident history data, traffic volume data, etc.). In other examples, the road segment safety rating may be based on historical data as well as driving behavior data of the operator of the vehicle. For instance, driving behaviors of the user may be determined based on, for instance, sensor data received from the vehicle. This driving behavior data may be used with the historical data to determine a road segment safety rating that is particular or unique to the driver or user. In still other examples, the road segment safety rating may be based on external or environmental factors, such as weather, current traffic, accidents, etc. that may impact the real-time risk associated with a road segment. Various combinations of these factors may also be used to determine a road segment safety rating.

[0007] In some examples, the determined road segment safety rating may be compared to a threshold. If the road segment safety rating is below the threshold, the system may generate one or more alternate road segments or route for the driver to consider. In some examples, the road segment safety rating may be used to determine an insurance premium or one or more insurance incentives to provide to the user.

[0008] Other features and advantages of the disclosure will be apparent from the additional description provided herein.

[0023] It will be apparent to one skilled in the art after review of the entirety disclosed that the steps illustrated in the figures listed above may be performed in other than the recited order, and that one or more steps illustrated in these figures may be optional.

[0024] In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration, various embodiments of the disclosure that may be practiced. It is to be understood that other embodiments may be utilized.

[0025] As will be appreciated by one of skill in the art upon reading the following disclosure, various aspects described herein may be embodied as a method, a computer system, or a computer program product. Accordingly, those aspects may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, such aspects may take the form of a computer program product stored by one or more computer-readable storage media having computer-readable program code, or instructions, embodied in or on the storage media. Any suitable computer-readable storage media may be utilized, including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and/or any combination thereof. In addition, various signals representing data or events as described herein may be transferred between a source and a destination in the form of electromagnetic waves traveling through signal-conducting media such as metal wires, optical fibers, and/or wireless transmission media (e.g., air and/or space).

[0026] In accordance with aspects of the invention, a new set of pricing tiers are disclosed herein for enabling safe driving and lower rates for insurance policy customers. In addition, various approaches to helping users mitigate risk are presented. In accordance with aspects of the invention, a computing device is disclosed for generating risk values in a data store. The system may receive various types of information, including but not limited to, accident information, geographic information, and vehicle information, from one or more data sources and calculate a risk value for associated road segments. Subsequently, the computing device may provide the associated risk value when provided with location information for a road segment such as regional location information and/or other information.

[0027] In an alternate embodiment in accordance with aspects of the invention, a personal navigation device, mobile device, and/or personal computing device may communicate with the database of risk values. The devices may receive information about a travel route and use that information to retrieve risk values for road segments in the travel route. The aggregate of the risk values is sent for display on a screen of the device or for recording in memory of the device. The contents of memory may also be uploaded to a data store for use by, e.g., insurance companies, to determine whether to adjust a quote for insurance coverage or one or more aspects of current insurance coverage such as premium, specific coverages, specific exclusions, rewards, special terms, etc.

[0028] In yet another embodiment, in accordance with aspects of the invention, a personal navigation device, mobile device, and/or personal computing device may access the database of risk values to assist in identifying and presenting alternate low-risk travel routes. The driver may select among the various travel routes presented, taking into account his/her tolerance for risk. Depending on the driver's selection, the vehicle's insurance policy may be adjusted accordingly, for either the current insurance policy or a future insurance policy.

[0029] Referring to FIG. 1, an example of a suitable operating environment in which various aspects of the invention may be implemented is shown in the architectural diagram of FIG. 1. The operating environment is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Other operating environments, systems, and the like will be described herein (e.g., in association with FIG. 13). The operating environment may be comprised of one or more data sources 104, 106 in communication with a computing device 102. The computing device 102 may use information communicated from the data sources 104, 106 to generate values that may be stored in a conventional database format. In one embodiment, the computing device 102 may be a high-end server computer with one or more processors 114 and memory 116 for storing and maintaining the values generated. The memory 116 storing and maintaining the values generated need not be physically located in the computing device 102. Rather, the memory (e.g., ROM, flash memory, hard drive memory, RAID memory, etc.) may be located in a remote data store (e.g., memory storage area) physically located outside the computing device 102, but in communication with the computing device 102.

[0030] A personal computing device 108 (e.g., a personal computer, tablet PC, handheld computing device, personal digital assistant, mobile device, etc.) may communicate with the computing device 102. Similarly, a personal navigation device 110 (e.g., a global positioning system (GPS), geographic information system (GIS), satellite navigation system, mobile device, other location tracking device, etc.) may communicate with the computing device 102. The communication between the computing device 102 and the other devices 108, 110 may be through wired or wireless communication networks and/or direct links. One or more networks may be in the form of a local area network (LAN) that has one or more of the well-known LAN topologies and may use a variety of different protocols, such as Ethernet. One or more of the networks may be in the form of a wide area network (WAN), such as the Internet. The computing device 102 and other devices (e.g., devices 108, 110) may be connected to one or more of the networks via twisted pair wires, coaxial cable, fiber optics, radio waves or other media. The term “network” as used herein and depicted in the drawings should be broadly interpreted to include not only systems in which devices and/or data sources are coupled together via one or more communication paths, but also stand-alone devices that may be coupled, from time to time, to such systems that have storage capability.

[0031] In another embodiment in accordance with aspects of the invention, a personal navigation device 110 may operate in a stand-alone manner by locally storing some of the database of values stored in the memory 116 of the computing device 102. For example, a personal navigation device 110 (e.g., a GPS in an automobile) may be comprised of a processor, memory, and/or input devices 118/output devices 120 (e.g., keypad, display screen, speaker, etc.). The memory may be comprised of a non-volatile memory that stores a database of values used in calculating an estimated route risk for identified routes. Therefore, the personal navigation device 110 need not communicate with a computing device 102 located at, for example, a remote location in order to calculate identified routes. Rather, the personal navigation device 110 may behave in a stand-alone manner and use its processor to calculate route risk values of identified routes. If desired, the personal navigation device 110 may be updated with an updated database of values after a period of time (e.g., an annual patch with new risk values determined over the prior year).

[0032] In yet another embodiment in accordance with aspects of the invention, a personal computing device 108 may operate in a stand-alone manner by locally storing some of the database of values stored in the memory 116 of the computing device 102. For example, a personal computing device 108 may be comprised of a processor, memory, input device (e.g., keypad, CD-ROM drive, DVD drive, etc.), and output device (e.g., display screen, printer, speaker, etc.). The memory may be comprised of CD-ROM media that stores values used in calculating an estimated route risk for an identified route. Therefore, the personal computing device 108 may use the input device to read the contents of the CD-ROM media in order to calculate a value for the identified route. Rather, the personal computing device 108 may behave in a stand-alone manner and use its processor to calculate a route risk value. If desired, the personal computing device 108 may be provided with an updated database of values (e.g., in the form of updated CD-ROM media) after a period of time. One skilled in the art will appreciate that personal computing device 108, 110, 112 need not be personal to a single user; rather, they may be shared among members of a family, company, etc.

[0033] The data sources 104, 106 may provide information to the computing device 102. In one embodiment in accordance with aspects of the invention, a data source may be a computer which contains memory storing data and is configured to provide information to the computing device 102. Some examples of providers of data sources in accordance with aspects of the invention include, but are not limited to, insurance companies, third-party insurance data providers, government entities, state highway patrol departments, local law enforcement agencies, state departments of transportation, federal transportation agencies, traffic information services, road hazard information sources, construction information sources, weather information services, geographic information services, vehicle manufacturers, vehicle safety organizations, and environmental information services. For privacy protection reasons, in some embodiments of the invention, access to the information in the data sources 104, 106 may be restricted to only authorized computing devices 102 and for only permissible purposes. For example, access to the data sources 104, 106 may be restricted to only those persons/entities that have signed an agreement (e.g., an electronic agreement) acknowledging their responsibilities with regard to the use and security to be accorded this information.

[0034] The computing device 102 uses the information from the data sources 104, 106 to generate values that may be used to calculate an estimated route risk. Some examples of the information that the data sources 104, 106 may provide to the computing device 102 include, but are not limited to, accident information, geographic information, and other types of information useful in generating a database of values for calculating an estimated route risk.

[0035] Some examples of accident information include, but are not limited to, loss type, applicable insurance coverage(s) (e.g., bodily injury, property damage, medical/personal injury protection, collision, comprehensive, rental reimbursement, towing), loss cost, number of distinct accidents for the segment, time relevancy validation, cause of loss (e.g., turned left into oncoming traffic, ran through red light, rear-ended while attempting to stop, rear-ended while changing lanes, sideswiped during normal driving, sideswiped while changing lanes, accident caused by tire failure (e.g., blow-out), accident caused by other malfunction of car, rolled over, caught on fire or exploded, immersed into a body of water or liquid, unknown, etc.), impact type (e.g., collision with another automobile, collision with cyclist, collision with pedestrian, collision with animal, collision with parked car, etc.), drugs or alcohol involved, pedestrian involved, wildlife involved, type of wildlife involved, speed of vehicle at time of incident, direction the vehicle is traveling immediately before the incident occurred, date of incident, time of day, night/day indicator (i.e., whether it was night or day at the time of the incident), temperature at time of incident, weather conditions at time of incident (e.g., sunny, downpour rain, light rain, snow, fog, ice, sleet, hail, wind, hurricane, etc.), road conditions at time of incident (e.g., wet pavement, dry pavement, etc.), and location (e.g., geographic coordinates, closest address, zip code, etc.) of vehicle at time of incident.

[0036] Accident information associated with vehicle accidents may be stored in a database format and may be compiled per segment. One skilled in the art will understand that the term segment may be interchangeably used to describe a road segment, intersection, round about, bridge, tunnel, ramp, parking lot, railroad crossing, or other feature that a vehicle may encounter along a route.

[0037] Time relevancy validation relates to the relevancy of historical accident information associated with a particular location. Time relevancy validation information may be dynamically created by comparing the time frames of accident information to the current date. For example, if a location or route had many collisions prior to five years ago but few since, perhaps a road improvement reduced the risk (such as adding a traffic light). Time relevancy information may be generated remotely and transmitted by a data source 104, 106 to the computing device 102 like other information. Alternatively, time relevancy information may be calculated at the computing device 102 using other information transmitted by a data source 104, 106. For example, the appropriateness of historical information may be related to the time frame into which the information belongs. Examples of time frames may include, but are not limited to, less than 1 year ago, 1 year ago, 2 years ago, 3 years ago, 4 years ago, 5 to 10 years ago, and greater than 10 years ago. In one embodiment, the more recent the historical information, the greater weight is attributed to the information.

[0038] Some examples of geographic information include, but are not limited to, location information and attribute information. Examples of attribute information include, but are not limited to, information about characteristics of a corresponding location described by some location information: posted speed limit, construction area indicator (i.e., whether location has construction), topography type (e.g., flat, rolling hills, steep hills, etc.), road type (e.g., residential, interstate, 4-lane separated highway, city street, country road, parking lot, etc.), road feature (e.g., intersection, gentle curve, blind curve, bridge, tunnel), number of intersections, whether a roundabout is present, number of railroad crossings, whether a passing zone is present, whether a merge is present, number of lanes, width of road/lanes, population density, condition of road (e.g., new, worn, severely damaged with sink-holes, severely damaged with erosion, gravel, dirt, paved, etc.), wildlife area, state, county, and/or municipality. Geographic information may also include other attribute information about road segments, intersections, bridges, tunnels, railroad crossings, and other roadway features.

[0039] Location information for an intersection may include the latitude and longitude (e.g., geographic coordinates) of the geometric center of the intersection. The location may be described in other embodiments using a closest address to the actual desired location or intersection. The intersection (i.e., location information) may also include information that describes the geographic boundaries, for example, of the intersection which includes all information that is associated within a circular area defined by the coordinates of the center of the intersection and points within a specified radius of the center. In another example of location information, a road segment may be defined by the latitude and longitude of its endpoints and/or an area defined by the road shape and a predetermined offset that forms a polygon. Segments may comprise intersections, bridges, tunnels, rail road crossings or other roadway types and features. Those skilled in the art will recognize that segments can be defined in many ways without departing from the spirit of this disclosed invention.

[0040] Some examples of vehicle information include, but are not limited to, information that describes vehicles that are associated with incidents (e.g., vehicle accidents, etc.) at a particular location (e.g., a location corresponding to location information describing a segment, intersection, etc.) Vehicle information may include vehicle make, vehicle model, vehicle year, and age. Vehicle information may also include information collected through one or more in-vehicle devices or systems such as an event data recorder (EDR), onboard diagnostic system, or global positioning satellite (GPS) device; examples of this information include speed at impact, brakes applied, throttle position, direction at impact, whether lights are on, whether windshield wipers are on, whether airbag deployed, etc. As is clear from the preceding examples, vehicle information may also include information about the driver of a vehicle being driven at the time of an incident. Other examples of driver information may include age, gender, marital status, occupation, alcohol level in blood, credit score, distance from home, cell phone usage (i.e., whether the driver was using a cell phone at the time of the incident), number of occupants.

[0041] In one embodiment in accordance with aspects of the invention, a data source 104 may provide the computing device 102 with accident information that is used to generate values (e.g., create new values and/or update existing values). The computing device 102 may use at least part of the received accident information to calculate a value, associate the value with a road segment (or other location information), and store the value in a database format. One skilled in the art will appreciate, after thorough review of the entirety disclosed herein, that there may be other types of information that may be useful in generating a database of values for use in, among other things, calculating an estimated route risk.

[0042] For example, in accordance with aspects of the invention, a data source 104 may provide the computing device 102 with geographic information that is used to generate new roadway feature risk values in a database of risk values and/or update existing risk values; where the roadway feature may comprise intersections, road segments, tunnels, bridges, or railroad crossings. Attributes associated with roadways may also be used in part to generate risk values. The computing device 102 may use at least part of the received geographic information to calculate a value, associate the value with a road segment (or other location information), and store the value in a database format. Numerous examples of geographic information were provided above. For example, a computing device 102 may receive geographic information corresponding to a road segment comprising accident information and roadway feature information and then calculate a risk value. Therefore, when calculating a risk value, the system may use, in one example, the geographic information and the accident information (if any accident information is provided). In alternative embodiments in accordance with aspects of the invention, the computing device may use accident information, geographic information, vehicle information, and/or other information, either alone or in combination, in calculating risk values in a database format.

[0043] The values generated by the computing device 102 may be associated with a road segment containing the accident location and stored in a data store. Similar to a point of interest (POI) stored in GPS systems, a point of risk (POR) is a road segment or point on a map that has risk information associated with it. Points of risk may arise because incidents (e.g., accidents) have occurred at these points before. In accordance with aspects of the invention, the road segment may be a predetermined length (e.g., ¼ mile) on a stretch of road. Alternatively, road segments may be points (i.e., where the predetermined length is minimal) on a road. Furthermore, in some embodiments, road segment may include one or more different roads that are no farther than a predetermined radius from a road segment identifier. Such an embodiment may be beneficial in a location, for example, where an unusually large number of streets intersect, and it may be impractical to designate a single road for a road segment.

[0044] Referring to FIG. 2, in accordance with aspects of the invention, a computing device 102 may receive accident information (in step 202), geographic information (in step 204), and/or vehicle information (in step 206). The computing device 102 may calculate (in step 212) the risk value for a road segment (or point of risk) by applying actuarial techniques to the information that may be received from data sources 104, 106. In one embodiment, the computing device 102 receives and stores the accident information in a data store with the latitude/longitude and time of the incident. The accident data is associated with a location and combined with other accident data associated with the same location (in step 210). Applying actuarial and/or statistical modeling techniques involving multiple predictors, such as generalized linear models and non-linear models, a risk value may be calculated (212), and the calculated risk value may be recorded in memory (116) (in step 214). The multiple predictors involved in the statistical model used to calculate a risk value may include accident information, geographic information, and vehicle information. Associating the risk value (in step 208) with a line segment and/or point which best pinpoints the area of the road in which the incident(s) occurred may be accomplished by using established GIS locating technology (e.g., GPS ascertaining a geographically determinable address, and assigning the data file to a segment's or intersection's formal address determined by the system). For example, two or more accidents located in an intersection or road segment may have slightly different addresses depending on where within the intersection or segment the accident location was determined to be. Therefore, the system may identify a location based on business rules. In another example business rules may identify an incident location using the address of the nearest intersection. In yet another example the system may identify the location of an incident on a highway using segments based on mileage markers or the lengths may be dynamically determined by creating segment lengths based on relatively equal normalized risk values. Therefore, roadways that have stretches with higher numbers of accidents may have shorter segments than stretches that have fewer accidents. In another example, if the incident occurred in a parking lot, the entire parking lot may be associated with a formal address that includes all accidents located within a determined area. One skilled in the art will appreciate after review of the entirety disclosed that road segment includes a segment of road, a point on a road, and other designations of a location (e.g., an entire parking lot).

[0045] For example, an insurance claim-handling processor may collect data about numerous incidents such as collision, theft, weather damage, and other events that cause any one of (or combination of) personal injury, vehicle damage, and damage to other vehicles or property. Information about the accident may be collected through artifacts such as first notice of loss (FNOL) reports and claim adjuster reports and may be stored in one or more data stores used by the insurer. Other data may also be collected at the point and time when the incident occurred, and this information (e.g., weather conditions, traffic conditions, vehicle speed, etc.) may be stored with the other accident information. The information in these data stores may be distributed by data sources 104, 106 in accordance with aspects of the invention. In addition, some information may also be recorded in third-party data sources that may be accessible to one or more insurance companies. For example, traffic information (e.g., traffic volume) and weather information may be retrieved in real-time (or near real-time) from their respective data sources.

[0046] Referring to FIG. 3, in accordance with aspects of the invention, the computing device 102 may send (in step 312) the risk value corresponding to a road segment when it receives location information (in step 302) requesting the risk associated with a particular location. The particular location information may be in the form of longitude/latitude coordinates, street address, intersection, closest address, or other form of information. Furthermore, in an alternative embodiment the accuracy of the risk value may be improved by submitting the direction that a vehicle travels (or may travel) through a road segment. The computing device 102 may receive (in step 304) the vehicle direction and use it to determine the risk value associated with the vehicle route. For example, a dangerous intersection demonstrates high risk to a vehicle/driver that passes through it. However, actuarial analysis (e.g., of data showing many recorded accidents at the location) may show that it is more dangerous if the driver is traveling northbound on the road segment and turns left. Therefore, the vehicle direction may also be considered when retrieving the appropriate risk value (in step 310).

[0047] Likewise, the computing device 102 may also receive (in step 308) other information to enhance the accuracy of the risk value associated with a travel route. For example, the computing device 102 may receive (in step 306) the time of day when the driver is driving (or plans to drive) through a particular travel route. This information may improve the accuracy of the risk value retrieved (in step 310) for the travel route. For example, a particular segment of road through a wilderness area may have a higher rate of accidents involving deer during the night hours, but no accidents during the daylight hours. Therefore, the time of day may also be considered when retrieving the appropriate risk value (in step 310). In addition, the computing device may receive (in step 308) other information to improve the accuracy of the risk value retrieved (in step 310) for a travel route. Some examples of this other information include, but are not limited to, the vehicle's speed (e.g., a vehicle without a sport suspension attempting to take a dangerous curve at a high speed), vehicle's speed compared to the posted speed limit, vehicle's speed compared to typical or average speed, etc.

[0048] In accordance with aspects of the invention, a computer-readable medium storing computer-executable instructions for performing the steps depicted in FIGS. 2 and 3 and/or described in the present disclosure is contemplated. The computer-executable instructions may be configured for execution by a processor (e.g., processor 114 in computing device 102) and stored in a memory (e.g., memory 116 in computing device 102). Furthermore, as explained earlier, the computer-readable medium may be embodied in a non-volatile memory (e.g., in a memory in personal navigation device 110) or portable media (e.g., CD-ROM, DVD-ROM, USB flash, etc. connected to personal computing device 108).

[0049] In accordance with aspects of the invention, a personal navigation device 110 may calculate a route risk value for a travel route of a vehicle. The personal navigation device 110 may be located, for example, in a driver's vehicle or in a mobile device 112 with location tracking capabilities. Alternatively, a personal computing device 108 may be used to calculate the route risk value for a travel route of a vehicle.

[0050] For example, referring to FIG. 4, a personal navigation device 110 may receive (in step 402) travel route information. The travel route information may include, but is not limited to, a start location, end location, road-by-road directions, and/or turn-by-turn directions. The personal navigation device 110 may use the travel route information and mapping software to determine the road segment upon which the vehicle will travel, and retrieve (in step 404) the risk value for that road segment. For each subsequent road segment remaining in the travel route (see step 406), the personal navigation device 110 may access the database of risk values to retrieve (in step 404) the risk value for that road segment. As explained earlier, the database of risk values may be stored locally to the personal navigation device 110, or may be stored remotely and accessed through a wired/wireless link to the data store.

[0051] The risk values retrieved (in step 404) for the travel route may be aggregated (in step 408) and a total risk value for the travel route may be sent (in step 410). In an alternate embodiment, the computing device 102 may count the number of each type of road risk along the travel route based on the values stored in the database. This number may then be multiplied by a risk-rating factor for the respective risk type. A risk type may comprise intersections, locations of past accidents along a route, railroad crossings, merges, roadway class (residential, local, commercial, rural, highways, limited access highways). Other risk types may include proximity to businesses that sell alcohol, churches or bingo parlors.

[0052] The sum of this product over all risk types may, in this alternate embodiment, equal the total route risk value. The total route risk value may be divided by the distance traveled to determine the route risk category for the travel route. For example, a route risk category may be assigned based on a set of route risk value ranges for low, medium, and high risk routes.

[0053] After being aggregated, the total risk value may be sent (in step 410) to a viewable display on the personal navigation device 110 or may be audible via a voice alert. Alternatively, the total risk value may be sent (in step 410) to a local/remote memory where it may be recorded and/or monitored. For example, it may be desirable for a safe driver to have her total risk value for all travel routes traveled over a time period to be uploaded to an insurance company's data store. The insurance company may then identify the driver as a lower-risk driver (e.g., a driver that travels on statistically lower-risk routes during lower-risk times) and provide the driver/vehicle with a discount and/or credit (in step 412) on an existing insurance policy (or towards a future insurance policy). At least one benefit of the aforementioned is that safe drivers are rewarded appropriately, while high-risk drivers are treated accordingly.

[0054] In some embodiments in accordance with aspects of the invention, the route risk value sent (in step 410) may be in the form of a number rating the risk of the travel route (e.g., a rating of 1 to 100 where 1 is very low risk and 100 is very high risk). Alternatively, the route risk value may be in the form of a predetermined category (e.g., low risk, medium risk, and high risk). At least one benefit of displaying the route risk value in this form is the simplicity of the resulting display for the driver. For example, an enhanced GPS unit may display a route (or segment of a route) in a red color to designate a high risk route, and a route may be displayed in a green color to designate a lower risk route. At least one benefit of a predetermined category for the route risk value is that it may be used as the means for comparing the amount of risk associated with each travel route when providing alternate routes. In addition, the enhanced GPS unit may alert the driver of a high risk road segment and offer the driver an incentive (e.g., monetary incentive, points, etc.) for avoiding that segment.

[0055] In accordance with aspects of the invention, a computer-readable medium storing computer-executable instructions for performing the steps depicted in FIG. 4 and/or described in the present disclosure is contemplated. The computer-executable instructions may be configured for execution by a processor (e.g., a processor in personal navigation device 110) and stored in a memory (e.g., flash memory in device 110).

[0056] When retrieving risk values, in accordance with aspects of the invention, one or more techniques, either alone or in combination, may be used for identifying and calculating the appropriate risk value for road segments. For example, under an accident cost severity rating (ACSR) approach, each point of risk has a value which measures how severe the average accident is for each point of risk. The value may be normalized and/or scaled by adjusting the range of the values. For example, under an ACSR approach using a range of values from 1 to 10: considering all accidents that occur in a predetermined area (e.g., road segment, state, zip code, municipality, etc.), the accidents in the top ten percentile of expensive accidents in that territory would get a 10 value and the lowest 10 percentile of costly accidents in that region would get a 1 value. The actual loss cost may be calculated by summing the various itemized loss costs (e.g., bodily injury, property damage, medical/personal injury protection, collision, comprehensive, uninsured/underinsured motorist, rental reimbursement, towing, etc.).

[0057] In an alternate embodiment, the ACSR approach may attribute varying weights to the different types of loss costs summed to calculate the actual loss cost. For example, after analyzing the information, certain portions of a loss cost (e.g., medical cost) may indicate risk more accurately than others. The importance of these portions may be weighted more heavily in the final loss cost calculation. Actuarial methods may be used to adjust loss cost data for a segment where a fluke accident may cause the calculated risk value to far exceed the risk value based on all the other data.

[0058] Under the accidents per year (APYR) approach, in accordance with aspects of the invention, each point of risk has a risk value that may reflect the average number of accidents a year for that individual point of risk. Under a modified APYR approach, the risk value for a point of risk continues to reflect the average number of accidents a year, but attributes a lesser weight to accidents that occurred a longer time ago, similar to time relevancy validation (e.g., it gives emphasis to recent accident occurrences over older occurrences).

[0059] Under the risk severity (RSR) approach, in accordance with aspects of the invention, each point of risk has a risk value that may reflect the severity of risk for that individual point of risk. For example, an intersection that is a frequent site of vehicle accident related deaths may warrant a very high risk value under the RSR approach. In one embodiment, risk severity rating may be based on accident frequency at intersections or in segments over a determined period of time. In another embodiment, the rating may be based on loss costs associated to intersections and segments. Yet another embodiment may combine accident frequency and severity to form a rating for a segment or intersection. One skilled in the art can recognize that risk severity ratings may be based on one or a combination of factors associated with intersections or segments.

[0060] Under the Environmental Risk Variable (ERV) approach, in accordance with aspects of the invention, each point of risk has a risk value that may reflect any or all information that is not derived from recorded accidents and/or claims, but that may be the (direct or indirect) cause of an accident. In one embodiment, the risk value under the ERV approach may be derived from vehicle information transmitted by a data source 104, 106. In an alternate embodiment, the EVR approach may use compound variables based on the presence or absence of multiple risk considerations which are known to frequently, or severely, cause accidents. A compound variable is one that accounts for the interactions of multiple risk considerations, whether environmental or derived from recorded accidents and/or claims. For example, driving through a wildlife crossing zone at dusk would generate a greater risk value than driving through this same area at noon. The interaction of time of day and location would be the compound variable. Another example may consider current weather conditions, time of day, day of the year, and topography of the road. A compound variable may be the type of infrequent situation which warrants presenting a verbal warning to a driver (e.g., using a speaker system in a personal navigation device 110 mounted in a vehicle) of a high risk route (e.g., a high risk road segments).

[0061] Another possible approach may be to calculate the route risk value using one or more of the approaches described above divided by the length of the route traveled. This may provide an average route risk value for use in conjunction with a mileage rating plan. In one embodiment, the system combines route risk and conventional mileage data to calculate risk per mile rating.

[0062] In one embodiment, a device in a vehicle (e.g., personal navigation device 110, mobile device 112, etc.) may record and locally store the route and/or the route and time during which a route was traveled. This travel route information may be uploaded via wireless/wired means (e.g., cell phones, manually using a computer port, etc.). This travel route information may be used to automatically query a data source 104, 106 for route rating information and calculate a total risk value.

[0063] Some accident data may be recorded and locally stored on a device (e.g., personal navigation device 110, mobile device 112, etc.) that provides incident location and a timestamp that can be used to synchronize other data located in data sources 104 and 106. The captured information may be periodically uploaded to computing device 102 for further processing of accident data for updating the road segment database in memory 116. In some embodiments, the other data may include local weather conditions, vehicle density on the roadway, and traffic signal status. Additional information comprising data from an in-vehicle monitoring system (e.g., event data recorder or onboard diagnostic system) may record operational status of the vehicle at the time of the incident. Alternatively, if the vehicle did not have a location tracking device, an insurance claims reporter may enter the address and other information into the data source manually. If the vehicle was configured with an in-vehicle monitoring system that has IEEE 802.11 Wi-Fi capabilities (or any other wireless communication capabilities), the travel route information may be periodically uploaded or uploaded in real-time (or near real-time) via a computer and/or router. The in-vehicle (or on-board vehicle) monitoring system may be configured to automatically upload travel route information (and other information) through a home wireless router to a computer. In some advanced monitoring systems, weather and traffic data (and other useful information) may be downloaded (in real-time or near real-time) to the vehicle. In some embodiments, it may be desirable to use mobile devices 112 (with the requisite capabilities) to transmit the information, provide GPS coordinates, and stream in data from other sources.

[0064] The risk types described above may be variables in a multivariate model of insurance losses, frequencies, severities, and/or pure premiums. Interactions of the variables would also be considered. The coefficient the model produces for each variable (along with the coefficient for any interaction terms) would be the value to apply to each risk type. The personal navigation device 110 may initially provide the quickest/shortest route from a start location A to an end location B, and then determine the route risk value by determining either the sum product of the number of each risk type and the value for that risk type or the overall product of the number of each risk type and the value for that risk type. (Traffic and weather conditions could either be included or excluded from the determination of the route risk value for comparison of routes. If not included, an adjustment may be made to the route risk value once the route has been traveled). The driver may be presented with an alternate route which is less risky than the initial route calculated, as will be discussed more fully herein. The personal navigation device 110 may display the difference in risk between the alternate routes and permit the driver to select the preferred route. In some embodiments in accordance with the invention, a driver/vehicle may be provided a monetary benefit (e.g., a credit towards a future insurance policy) for selecting a less risky route.

[0065] In one example in accordance with aspects of the invention, a driver may enter a starting location and an end location into a personal navigation device 110. The personal navigation device 110 may present the driver with an illustrative 2-mile route that travels on a residential road near the following risks: 5 intersections, 3 past accident sites, 1 railroad crossing, and 1 lane merging site. Assuming for illustrative purposes that the following risk values apply to the following risk types:

	Risk Type	Risk-rating Factor
	Intersections	55
	Past Accidents	30
	Railroad Crossing	5
	Merge	60
	Residential Road	2 per mile

[0066] Then, the route risk value for the entire 2-mile route may be calculated, in one embodiment of the invention, as follows:

Risk Type	Risk-rating Factor	Count	Product
Intersections	55	5	55*5 = 275
Past Accidents	30	3	30*3 = 90
Railroad Crossing	5	1	5*1 = 5
Merge	60	1	60*1 = 60
Residential Road	2 per mile	2	2*2 = 4
Sum Total			434

[0067] Assuming a route risk value between 0 and 350 (per mile) is categorized as a low-risk route, then the aforementioned 2-mile route's risk value of 217 (i.e., 434 divided by 2) classifies it a low-risk route.

[0068] In some embodiments, for rating purposes the route risk value may consider the driving information of the driver/vehicle. For example, the personal navigation device 110 (or other device) may record the route taken, as well as the time of day/month/year, weather conditions, traffic conditions, and the actual speed driven compared to the posted speed limit. The current weather and traffic conditions may be recorded from a data source 104, 106. Weather conditions and traffic conditions may be categorized to determine the risk type to apply. The posted speed limits may be included in the geographic information. For each segment of road with a different posted speed limit, the actual speed driven may be compared to the posted speed limit. The difference may be averaged over the entire distance of the route. In addition, various techniques may be used to handle the amount of time stopped in traffic, at traffic lights, etc. One illustrative technique may be to only count the amount of time spent driving over the speed limit and determine the average speed over the speed limit during that time. Another illustrative method may be to exclude from the total amount of time the portion where the vehicle is not moving. Then, upon completion of the trip, the route risk value may be calculated and stored in memory along with the other information related to the route risk score and mileage traveled. This information may later be transmitted to an insurance company's data store, as was described above.

[0069] In another embodiment in accordance with aspects of the invention, real time data may be used to dynamically assign risk values to each point of risk. For example, some road segments may have a higher risk value when a vehicle travels through at a time when, e.g., snowfall is heavy. In such situations, a dynamic risk value may be applied to the road segment to determine the appropriate route risk value to assign to the route.

[0070] Referring to FIG. 5, in accordance with aspects of the invention, a method of selling a vehicular insurance policy is illustrated. A vehicle owner or driver may be provided (in step 502) with an insurance policy with a total risk score. The total risk score (e.g., 500) indicates the quantity of risk the vehicle is permitted to travel through before the insurance policy must be renewed or becomes terminated. For example, as the vehicle is driven over various travel routes, the route risk values for the road segments traveled are deducted (in step 504) from the total risk score of the insurance policy. The vehicle owner and/or driver may be provided (in step 506) an option to renew the insurance policy (e.g., to purchase additional risk points to apply towards the total risk score of the insurance policy). Once the total risk score falls to zero or under (see step 508), the vehicle owner and/or driver (or any other person/entity authorized to renew the policy) is provided (in step 510) with a final option to renew the insurance policy before the insurance policy terminates (in step 512). It will be apparent to one skilled in the art after review of the entirety disclosed that the embodiment illustrated above may benefit from a personal navigation device 110 (or similar device) to monitor and record the route traveled by a vehicle. At least one benefit of the insurance policy illustrated by FIG. 5 is the ability to pay per quantity of risk consumed instead of paying only a fixed premium.

[0071] In another embodiment in accordance with aspects of the invention, route-dependent pricing uses route risk values to adjust insurance pricing based on where a vehicle is driven. Contrary to the embodiment above where the vehicle's insurance policy terminated dependent on the quantity of risk consumed by the vehicle's travel route, in this embodiment, an insurance company (or its representatives, e.g., agent) may adjust the price quoted/charged for an insurance policy based on risk consumed. In this embodiment, a vehicle/driver may be categorized into a risk class (e.g., low-risk, medium-risk, high risk, etc.) and charged for insurance accordingly. For example, the vehicle/driver may be provided with notification of a credit/debit if the vehicle consumed less/more, respectively, of risk at the end of a policy term than was initially purchased.

[0072] In another embodiment: the insurance policy is sold and priced in part based on where a customer falls within a three sigma distribution of risk units consumed by all insured per a typical policy period. The policy pricing may be based on an initial assumption of risk to be consumed in the prospective policy period or may be based on risk consumed in a preceding policy period. In a case where the number of risk units consumed is greater than estimated, the customer may be billed for the overage at the end of (or during) the policy period. In yet another embodiment, the system may be provided as a pay-as-you-drive coverage where the customer is charged in part based on the actual risk units consumed in the billing cycle. The system may include a telematics device that monitors, records, and periodically transmits the consumption of risk units to processor 114 that may automatically bill or deduct the cost from an account.

[0073] While the invention has been described with respect to specific examples including presently exemplary modes of carrying out the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above-described systems and techniques that fall within the spirit and scope of the invention.

[0074] FIG. 6 is a schematic diagram of an illustrative road segment safety rating system 600. The road segment safety rating system 600 may be associated with, internal to, operated by, or the like, an entity 601, such as an insurance provider. In some examples, the entity may be one of various other types of entities, such as a government entity, corporation or business, university, or the like. Various examples described herein will be discussed in the context of an insurance provider. However, nothing in the specification should be viewed as limiting use of the systems, methods, arrangements, etc. described herein to use only by an insurance provider.

[0075] The road segment safety rating system 600 may include one or more modules that may include hardware and/or software configured to perform various functions within the system 600. The one or more modules may be separate, physical devices or, in other examples, one or more modules may be part of the same physical device.

[0076] The road segment safety rating system 600 may include a road segment safety rating module 602. The road segment safety rating module 602 may receive data from one or more data stores, such as data stores 604 and 606, and may determine a safety rating for one or more road segments. In some examples, the safety rating of the road segment may correspond to a risk value of the road segment, as described herein. In other examples, the safety rating of the road segment may be a different value determined as described herein. In some examples, a road segment may be some or all of a particular road. As discussed above, the road segments may have varying lengths or distances, may be formed of various materials, may include various types of roads (e.g., highway, country road, etc.), and the like.

[0077] As indicated above, at least some of the data used to determine the road segment safety rating may be received from one or more data stores. The data stores may be associated with or internal to the entity 601, such as data store 604, or may be external to the entity 601, such as data store 606. Data that may be used to determine a road segment safety rating may include historical accident information associated with a particular road segment, traffic volume information associated with a particular road segment, severity of accident associated with a particular road segment (e.g., based on previously received insurance claim data), and the like. In some examples, geocoded data may be received by the system 600 (e.g., from data store 606) and may be used to determine a risk value and/or road segment safety rating. In some arrangements, additional information such as type of road segment (2-lane highway, 4-lane highway, rural road, etc.), condition of road segment (e.g., newly resurfaced, severely damaged, etc.), and the like (as discussed above), may be used to determine the road segment safety rating.

[0078] Accordingly, some information may be received by the road segment safety rating module 602 from internal data store 604. The internal data store 604 may include information associated with accidents associated with the road segment, accidents associated with that type of road or one or more features of the road segment (e.g., number of bends, merging, etc.), severity of accidents associated with the road segment (e.g., based on insurance claim data), number of accidents associated with the road segment, time of day of accident, date of accident, and the like. Accident information received from internal data store 604 may be collected from historical accident or claim information of the insurance provider entity 601. The internal data store 604 may also include information associated with conditions of the road segment (e.g., pot holes, type of road, etc.). In some arrangements, this information may be received from a telematics device associated with one or more vehicles, and associated sensors detecting such information. The received telematics data may be stored and used to determine, for example, a road segment safety rating.

[0079] External data store 606 may provide additional information to the system 600. For instance, external data store may provide additional information associated with the type of road, condition of the road, etc. Further, external data store 606 may include information gathered from various sources regarding accidents associated with the road segment, traffic volume associated with the road segment, and the like. As discussed above, the accident information may be received from a third party and/or coded to identify the road segment, type of accident, severity of accident, and the like. In some examples, external data store 606 may include information associated with environmental or weather conditions surrounding a road segment. Accordingly, a road segment safety rating may be generated in real-time, or near real-time, and may include current weather conditions (e.g., rain, snow, fog, etc.). Some example algorithms that may be used to determine a road segment safety rating are provided below. The example algorithms provided are merely examples and various other algorithms may be used to determine road segment safety rating without departing from the invention.

[0080] In some examples, the road segment safety rating may be based on static variables (e.g., variables that do not change rapidly or frequently). For instance, one example algorithm may be:

Road safety rating=exp(prior accident frequency on the road segment*W₁+road curvature*W₂+road segment has lane merge*W₃+road segment has merge from left*W₄).

[0081] W₁ though W₄ may be weighting factors applied to each variable.

[0082] In other examples, the road segment safety rating may be based on a combination of static factors (similar to the equation above) as well as some dynamic road factors (e.g., factors associated with the road segment that may change rapidly or frequently). For instance,

Road segment safety rating=exp(prior accident frequency on the road segment*W₁+road curvature*W₂+road segment has lane merge*W₃+road segment has merge from left*W₄+road segment has construction*W₅+number of inches of snow on road segment*W₆+road segment is wet*W₇+traffic factor*W₈).

[0083] In this example algorithm, W₁ though W₈ represent weighting factors and variables such as road segment has construction, number of inches of snow on road segment, road segment is wet, and traffic factor may be dynamic factors used in combination with the static factors described above.

[0084] In still other examples, the road segment safety rating may be based on static factors, dynamic factors, as well as one or more driver behavior factors. For instance,

Road segment safety rating=exp(prior accident frequency on the road segment*W₁+road curvature*W₂+road segment has lane merge*W₃+road segment has merge from left*W₄+road segment has construction*W₅+number of inches of snow on road segment*W₆+road segment is wet*W₇+traffic factor*W₈+(road curvature*driver takes curves fast*W₉)+(number of inches of snow*driver brakes hard*W₁₀)).

[0085] In this example, W₁ through W₁₀ are weighting factors and variables such as “driver takes curve fast” and “driver brakes hard” are example driving behaviors that may be used to determine a road segment safety rating particular to a driver.

[0086] As indicated above, various other algorithms, various different weighting factors, additional or different variables, etc. may be used without departing from the invention. The above-described algorithms are merely some examples of algorithms that may be used to determine a road segment safety rating and should not be viewed as limiting the invention to only those example algorithms provided.

[0087] Accordingly, the road segment safety rating module 602 may detect a location of a vehicle (e.g., via global positioning system (GPS) data collected from the vehicle) and may identify a road segment associated with the location of the vehicle. This identification of the road segment may be performed by comparing the location coordinates from the vehicle to location coordinates of roads obtained, for example, from a mapping company or form analysis of many vehicle's location coordinates over time. The road segment safety rating module 602 may then receive data from various data stores, such as data store 604 and/or data store 606, and may generate a road segment safety rating for the identified road segment. The safety rating may be transmitted to a computing device of a user, such as one or more of computing devices 608a-608f. For instance, the road segment safety rating may be transmitted to a smart phone 608a, personal digital assistance 608b, tablet computing device 608c, cell phone 608d, on-board vehicle computing device 608f, or other computing device 608e.

[0088] In some arrangements, the road segment safety rating may be generated by the road segment safety module 602 based on data associated with the road segment, as discussed above, as well as data associated with a driver of the vehicle. For instance, driver-specific data may be received by the road segment safety rating module 602 and may be used in conjunction with the various types of data discussed above, to determine a road segment safety rating for a particular road segment. For instance, the system 600 may include a plurality of sensors 610. The sensors 610 may be any of various types of sensors, as will be discussed more fully herein. The sensors 610 may be used to obtain data associated with driving behaviors of the user, such as hard braking, speeding, and the like. In another example, one or more sensors may be used to detect environmental conditions such as precipitation, humidity, cloud cover, or the like. In still another example, one or more sensors may be used to determine road conditions or to obtain information from outside sources (e.g., external databases, or the like) regarding traffic conditions, types of road (e.g., two-lane road, four-lane road), speed limit of the road, or the like. The data from one or more sensors 610, which may include data from combinations of different types of sensors, may be transmitted to driving behavior module 612 for analysis.

[0089] The driving behavior module 612 may analyze sensor data received from one or more of sensors 610 and may identify one or more driving behaviors of a particular driver or operator of the vehicle. For instance, the driving behavior module 612 may determine whether the user generally drives at a speed over the speed limit, generally follows too closely behind a vehicle in front of him, generally brakes hard, and the like. This information may be transmitted to the road segment safety rating module 602 for use in determining a safety rating for a particular road segment.

[0090] For instance, the user data received from the driving behavior module 612 may be combined with data received from the one or more data stores (e.g., 604, 606) to determine a road segment safety rating that is particular to, or unique to, the user or current operator of the vehicle. Accordingly, while a particular road segment may have a first safety rating for driver 1, the road segment may have a second, different safety rating for driver 2, based on the different driving behaviors of driver 1 and driver 2. Thus, any recommendations for alternate routes may account for the type of driving behavior of the current user or operator of the vehicle, as will be discussed more fully herein.

[0091] In some arrangements, raw sensor data (e.g., from one or more of sensors 610) may be used in conjunction with other data (e.g., from data store 604, 606) to generate the road segment safety rating. For instance, one or more sensors may be used to detect precipitation. That information may be provided to the road segment safety rating module 602 in real-time, or near real-time, and may be combined with other data (e.g., accident data, traffic volume data, etc.) for the road segment, and/or user driving behavior data, to generate or determine the road segment safety rating for the road segment. In some examples, based on this real-time or near real-time data, any risks identified (e.g., risks appearing along the route being traveled) may be transmitted to the user, via an audible warning or alert to displayed on a computing device, such as an on-board vehicle computing device, mobile device of the user, etc. The risks may be unique to the driver based on driving characteristic data collected for the user, as well as current external or environmental conditions.

[0092] Road segment safety rating system 600 may further include a recommendation module 614. The recommendation module 614 may generate, or be configured to generate, one or more recommendations for alternate road segments that may have a safer rating than, for instance, a road segment on which the vehicle is currently travelling or will be travelling. In some examples, historical road segment safety rating data may be stored, for instance, in a data table. Accordingly, upon generating a road segment safety rating (e.g., by the road segment safety rating module 602), the determined safety rating may be transmitted to the recommendation module 614. The recommendation module 614 may evaluate the safety rating to determine whether it is at or above a pre-determined safety threshold. For instance, a system may identify a minimum threshold for road segments to be considered safe. If the determined safety rating is at or above the threshold, the recommendation module 614 may store the rating (e.g., in the data table) for further consideration.

[0093] As another example, before the driver starts driving, they may enter their intended destination (or their probable or expected destination could be predicted) into a computing device (e.g., mobile device, on-board vehicle computing device, or the like) which then obtains travel time and risk estimates for a number of potential road segments to be traveled upon. An optimization function may run to determine a path or route from the current location to the destination that minimizes travel time, road risks, and/or combinations thereof. For instance, one example combination of travel time and road risk that may be used may be: 2.1*travel_time+1.4*road_risk. Other considerations may be included in this quantity to be minimized such as toll roads, nice scenery to look at, freeways or lack thereof, etc. Weights on the various variables in the quantity to be minimized could be entered by the user before the trip, or could be determined, such as by a computing device, over time by observing or collecting data from the driver's trips for a predetermined period of time.

[0094] If the recommendation module 614 determines that the safety rating is below the pre-determined threshold, the module 614 may identify one or more alternate road segments that may be used in lieu of the current road segment. Identification of alternate road segments may be performed by comparing the current road segment with other road segments in the same or similar geographic area that have a higher safety rating or a safety rating above the threshold. The recommendation(s) may be transmitted to a user, such as via one or more of computing devices 608a-608f.

[0095] As mentioned above, the recommendation module 614 may also consider driving behaviors of the driver or operator of the vehicle when generating one or more recommendations. For instance, the recommendation module 614 may consider driving behavior data, such as that received from the driving behavior module 612, when identifying alternate road segment. For instance, a driver who is identified as generally driving below the speed limit may be provided with alternate road segments that are lower volume traffic roads, rather than busy highways, in which the user may be able to proceed more slowly without disrupting traffic or causing an accident.

[0096] The road segment safety rating system 600 may further include an insurance rate module 616. The insurance rate module 616 may store information associated with various users and insurance policies associated with those users. In some examples, road segment safety rating information may be used to determine an insurance rate for a user. For instance, a history of travelling on higher safety rated road segments may be an indication of less risk associated with insuring the user and, thus, the user may be provided with a lower insurance premium than other users who travel on lower safety rated road segments. In another example, a user who travels on road segments having a high safety rating may be provided with a discount or other insurance incentive for his or her driving behavior. In some arrangements, the system may generate and/or offer to the user (e.g., via computing device 608) one or more discounts or insurance incentives to implement the recommendations provided by the recommendation module 614.

[0097] In some example arrangements, a user may have a pay as you drive type of insurance policy. That is, the user may pay for a pool of insurance credit (e.g., units of credit) that may be reduced based on the driving behaviors of the user. Accordingly, in such examples, the insurance credit may be reduced at a faster rate when the driver is travelling on road segments with a lower safety rating than road segments with a higher safety rating.

[0098] Although many examples described herein indicate that a higher safety rating is better or safer than a lower safety rating (e.g., on a scale of 1-100, a 100 would be a safer rating than a 1), this is merely one example road segment safety rating arrangement. Various scales and arrangements (e.g., a scale of 1-10 with 10 being the least safe, etc.) may be used without departing from the invention. Also, as discussed above, the road segment safety rating may be the same as, or similar to the risk value discussed above. In other examples, the road segment safety rating may be a different value or may be derived from the risk value discussed above (e.g., 100−determined risk value=road segment safety rating).

[0099] The road segment safety rating determined herein may be combined with safety ratings for a plurality of other road segments to establish an overall route or trip safety rating. In these examples, the overall safety rating of a route may be determined and, if the safety rating is below a pre-determined threshold, one or more recommendations for alternate routes may be identified and/or communicated to the user.

[0100] FIG. 7 is a diagram of an illustrative driving analysis system 700 including additional aspects of the road segment safety rating system 700 shown in FIG. 6 and/or implementing the road segment safety rating system 600 of FIG. 6. The system 700 includes a vehicle 710, a personal mobile device 730, an insurance system server 750, and additional related components. As discussed below, the components of the system 700, individually or using communication and collaborative interaction, may determine, present, and implement various types of road segment safety ratings to customers, including generating a road segment safety rating based on road segment data and/or user driving behavior data, determining whether the safety rating is above a pre-determined threshold, identifying alternate road segments, and/or communicating alternate road segments to a user, etc. To perform such features, the components shown in FIG. 7 each may be implemented in hardware, software, or a combination of the two. Additionally, each component of the system 700 may include a computing device (or system) having some or all of the structural components described herein for computing device 102 in FIG. 1 and/or computing device 1301 in FIG. 13.

[0101] Vehicle 710 in the system 700 may be, for example, an automobile, a motorcycle, a scooter, a bus, a recreational vehicle, a boat, or other vehicle for which vehicle data, location data, driver data (or operator data), operational data and/or other driving data (e.g., location data, time data, weather data, etc.) may be collected and analyzed. The vehicle 710 includes vehicle operation sensor 711 (similar to one or more of sensors 610a-610c of FIG. 6) capable of detecting and recording various conditions at the vehicle and operational parameters of the vehicle. For example, sensor 711 may detect and store data corresponding to the vehicle's location (e.g., GPS coordinates), time, travel time, speed and direction, rates of acceleration or braking, gas mileage, and specific instances of sudden acceleration, braking, swerving, and distance traveled. Sensor 711 also may detect and store data received from the vehicle's 710 internal systems, such as impact to the body of the vehicle, air bag deployment, headlights usage, brake light operation, door opening and closing, door locking and unlocking, cruise control usage, hazard lights usage, windshield wiper usage, horn usage, turn signal usage, seat belt usage, phone and radio usage within the vehicle, autonomous driving system usage, maintenance performed on the vehicle, and other data collected by the vehicle's computer systems, including the vehicle on-board diagnostic systems (OBD).

[0102] Additional sensors 711 may detect and store the external driving conditions, for example, external temperature, rain, snow, light levels, and sun position for driver visibility. For example, external cameras and proximity sensors 711 may detect other nearby vehicles, vehicle spacing, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a driving data/behavior analysis. Sensor 711 also may detect and store data relating to moving violations and the observance of traffic signals and signs by the vehicle 710. Additional sensors 711 may detect and store data relating to the maintenance of the vehicle 710, such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure.

[0103] Vehicle sensor 711 also may include cameras and/or proximity sensors capable of recording additional conditions inside or outside of the vehicle 710. For example, internal cameras may detect conditions such as the number of the passengers and the types of passengers (e.g. adults, children, teenagers, pets, etc.) in the vehicles, and potential sources of driver distraction within the vehicle (e.g., pets, phone usage, and unsecured objects in the vehicle). Sensor 711 also may be configured to collect data identifying a current driver from among a number of different possible drivers, for example, based on driver's seat and mirror positioning, driving times and routes, radio usage, etc. Voice/sound data along with directional data also may be used to determine a seating position within a vehicle 710. Sensor 711 also may be configured to collect data relating to a driver's movements or the condition of a driver. For example, vehicle 710 may include sensors that monitor a driver's movements, such as the driver's eye position and/or head position, etc. Additional sensors 711 may collect data regarding the physical or mental state of the driver, such as fatigue or intoxication. The condition of the driver may be determined through the movements of the driver or through other sensors, for example, sensors that detect the content of alcohol in the air or blood alcohol content of the driver, such as a breathalyzer, along with other biometric sensors.

[0104] Certain vehicle sensors 711 also may collect information regarding the driver's route choice, whether the driver follows a given route, and to classify the type of trip (e.g. commute, errand, new route, etc.) and type of driving (e.g., continuous driving, parking, stop-and-go traffic, etc.). In certain embodiments, sensors and/or cameras 711 may determine when and how often the vehicle 710 stays in a single lane or strays into other lane. A Global Positioning System (GPS), locational sensors positioned inside the vehicle 710, and/or locational sensors or devices external to the vehicle 710 may be used to determine the route, speed, lane position, road-type (e.g. highway, entrance/exit ramp, residential area, etc.) and other vehicle position/location data.

[0105] The data collected by vehicle sensor 711 may be stored and/or analyzed within the vehicle 710, such as for example a driving analysis computer 714 integrated into the vehicle, and/or may be transmitted to one or more external devices. For example, as shown in FIG. 7, sensor data may be transmitted via short-range communication systems 712 or other communication networks (e.g., WAN or cellular networks) to other nearby vehicles. Additionally, the sensor data may be transmitted via a telematics device 713 to one or more remote computing devices, such as personal mobile device 730, insurance system server 750, and/or other remote devices.

[0106] Short-range communication system 712 is a vehicle-based data transmission system configured to transmit vehicle operational data to other nearby vehicles or infrastructure, and to receive vehicle operational data from other nearby vehicles. In some examples, communication system 712 may use the dedicated short-range communications (DSRC) protocols and standards to perform wireless communications between vehicles. In the United States, 75 MHz in the 5.850-5.925 GHz band have been allocated for DSRC systems and applications, and various other DSRC allocations have been defined in other countries and jurisdictions. However, short-range communication system 712 need not use DSRC, and may be implemented using other short-range wireless protocols in other examples, such as WLAN communication protocols (e.g., IEEE 802.11), Bluetooth (e.g., IEEE 802.15.1), or one or more of the Communication Access for Land Mobiles (CALM) wireless communication protocols and air interfaces. The vehicle-to-vehicle (V2V) transmissions between short-range communication system 712 and other systems may be sent via DSRC, Bluetooth, satellite, GSM infrared, IEEE 802.11, WiMAX, RFID, and/or any suitable wireless communication media, standards, and protocols. In certain systems, short-range communication system 712 may include specialized hardware installed in vehicles 710 (e.g., transceivers, antennas, etc.), while in other examples the communication system 712 may be implemented using existing vehicle hardware components (e.g., radio and satellite equipment, navigation computers) or may be implemented by software running on the mobile device 730 of a driver and/or passengers within the vehicle 710.

[0107] V2V communications also may include vehicle-to-infrastructure (V2I) communications, such as transmissions from vehicles to non-vehicle receiving devices, for example, toll booths, rail road crossings, and road-side traffic monitoring devices. Certain V2V communication systems may periodically broadcast data from a vehicle 710 to any other vehicle, or other infrastructure device capable of receiving the communication, within the range of the vehicle's transmission capabilities. The range of V2V communications and V2I communications may depend on the wireless communication standards and protocols used, the transmission/reception hardware (e.g., transceivers, power sources, antennas), and other factors. Short-range V2V (and V2I) communications may range from just a few feet to many miles, and different types of driving behaviors may be determined depending on the range of the V2V communications. For example, V2V communications ranging only a few feet may be sufficient for a driving analysis computing device 714 in one vehicle to determine that another vehicle is tailgating or cut-off the vehicle, whereas longer communications may allow the device 714 to determine additional types of driving behaviors (e.g., vehicle spacing, yielding, defensive avoidance, proper response to a safety hazard, etc.) and driving conditions (e.g., traffic, road conditions, weather conditions, etc.).

[0108] The types of vehicle operational data, or vehicle driving data, transmitted by vehicle 710 may depend on the protocols and standards used for the V2V and V2I communication, the range of communications, the autonomous driving system, and other factors. In certain examples, vehicles 710 may periodically broadcast corresponding sets of similar vehicle driving data, such as the location (which may include an absolute location in GPS coordinates or other coordinate systems, and/or a relative location with respect to another vehicle or a fixed point), speed, and direction of travel. In certain examples, the nodes in a V2V communication system (e.g., vehicles and other reception devices) may use internal clocks with synchronized time signals, and may send transmission times within V2V communications, so that the receiver may calculate its distance from the transmitting node based on the difference between the transmission time and the reception time. The state or usage of the vehicle's 710 controls and instruments may also be transmitted, for example, whether the vehicle is accelerating, braking, turning, and by how much, and/or which of the vehicle's instruments are currently activated by the driver (e.g., head lights, turn signals, hazard lights, cruise control, 4-wheel drive, traction control, etc.). Vehicle warnings such as detection by the vehicle's 710 internal systems that the vehicle is skidding, that an impact has occurred, or that the vehicle's airbags have been deployed, also may be transmitted in V2V communications.

[0109] As shown in FIG. 7, the data collected by vehicle sensor 711 may be transmitted to an insurance system server 750, personal mobile device 730, and/or additional external servers and devices via telematics device 713. Telematics device 713 may be one or more computing devices containing many or all of the hardware/software components as the computing device 1301 depicted in FIG. 13. As discussed above, the telematics device 713 may receive vehicle operation data and driving data from vehicle sensor 711, and may transmit the data to one or more external computer systems (e.g., insurance system server 750 of an insurance company, financial institution, or other entity) over a wireless transmission network. Telematics device 713 also may be configured to detect or determine additional types of data relating to real-time driving and the condition of the vehicle 710. The telematics device 713 also may store the type of vehicle 710, for example, the make, model, trim (or sub-model), year, and/or engine specifications, autonomous driving system specifications, as well as other information such as vehicle owner or driver information, insurance information, and financing information for the vehicle 710.

[0110] In the example shown in FIG. 7, telematics device 713 may receive vehicle driving data from vehicle sensor 711, and may transmit the data to an insurance system server 750. However, in other examples, one or more of the vehicle sensors 711 or systems may be configured to receive and transmit data directly from or to an insurance system server 750 without using a telematics device. For instance, telematics device 713 may be configured to receive and transmit data from certain vehicle sensors 711 or systems, while other sensors or systems may be configured to directly receive and/or transmit data to an insurance system server 750 without using the telematics device 713. Thus, telematics device 713 may be optional in certain embodiments.

[0111] In certain embodiments, vehicle sensors, vehicle on-board diagnostic systems (OBDs) and other vehicle-based systems and/or vehicle communication systems, may collect and/or transmit data pertaining to autonomous driving of the vehicles. In autonomous driving, the vehicle fulfills all or part of the driving without being piloted by a human. An autonomous car can be also referred to as a driverless car, self-driving car, or robot car. For example, in autonomous driving, a vehicle control computer 717 may be configured to operate all or some aspects of the vehicle driving, including but not limited to acceleration, braking, steering, and/or route navigation. A vehicle with an autonomous driving capability may sense its surroundings using the vehicle sensor 711 and/or receive inputs regarding control of the vehicle from the vehicle communications systems, including but not limited to short range communication system 712 telematics device 713, or other vehicle communication systems.

[0112] The system 700 in FIG. 7 also includes a mobile device 730. Mobile device 730 may be, for example, a smartphone or other mobile phone, personal digital assistant (PDA), tablet computer, and the like, and may include some or all of the elements described herein with respect to the computing device 1301 in FIG. 13. As shown in this example, some mobile devices in systems 700 (e.g., mobile device 730) may be configured to establish communication sessions with vehicle-based devices and various internal components of vehicle 710 via wireless networks or wired connections (e.g., for docked devices), whereby such mobile device 730 may have secure access to internal vehicle sensors 711 and other vehicle-based systems. However, in other examples, the mobile device 730 might not connect to vehicle-based computing devices and internal components, but may operate independently by communicating with vehicle 710 via their standard communication interfaces (e.g., telematics device 713, etc.), or might not connect at all to vehicle 710.

[0113] Mobile device 730 may include a network interface 732, which may include various network interface hardware (e.g., adapters, modems, wireless transceivers, etc.) and software components to enable mobile device 730 to communicate with insurance system server 750, vehicle 710, and various other external computing devices. One or more specialized software applications, such as a driving analysis application 734 and/or a road segment safety rating application 735 may be stored in the memory of the mobile device 730. The driving analysis application 734 and road segment safety rating application 735 may be received via network interface 732 from the insurance server 750, vehicle 710, or other application providers (e.g., application stores). As discussed below, the driving analysis application 734 and road segment safety rating application 735 may or may not include various user interface screens, and may be configured to run as user-initiated applications or as background applications. The memory of the mobile device 730 also may include databases configured to receive and store vehicle data, driving data, driving trip data, and the like, associated with one or more drivers and/or vehicles.

[0114] Like the vehicle-based computing devices in vehicle 710, mobile device 730 also may include various components configured to generate and/or receive vehicle data, driver data, and driving data or other operational data. For example, using data from the GPS receiver 733, a driving analysis software application 734 may be able to identify starting and stopping points of driving trips, determine driving speeds, times, routes, road segments, and the like. Additional components of mobile device 730 may be used to generate or receive driving data for the driving data analysis application 734 and/or road segment safety rating application 735, such as an accelerometer, compass, and various cameras and proximity sensors. As discussed below, these and other mobile device components may be used to receive, store, and output various user/driver data, to identify starting and stopping points and other characteristics of driving trips, identify road segments, to determine various driving data such as speeds, driving routes and times, acceleration, braking, and turning data, and other driving conditions and behaviors. In some implementations, the driving analysis software application 734 may store and analyze the data from various mobile device components, and the road segment safety rating application 735 may use this data, alone or in any combination with other components or devices (e.g., insurance server 750), to determine and present road segment safety ratings, recommended alternate road segments, insurance costs or incentives, and the like.

[0115] When mobile computing devices within vehicles are used to detect vehicle driving data and/or to receive vehicle driving data from vehicle sensors, such mobile computing devices 730 may store, analyze, and/or transmit the vehicle driver data (e.g., data identifying a current driver), driving data (e.g., speed data, acceleration, braking, and turning data, and any other vehicle sensor or operational data), and driving trip data (e.g., road segment, driving route, driving times, driving destinations, etc.), to one or more other devices. For example, mobile computing device 730 may transmit driver data, driving data and driving behaviors, and driving trip data directly to one or more insurance servers 750, and thus may be used in conjunction with or instead of telematics devices 713. Additionally, mobile computing device 730 may be configured to perform the V2V and V2I communications described above, by establishing connections and transmitting/receiving vehicle driving data to and from other nearby vehicles. Thus, mobile computing device 730 may be used in conjunction with, or instead of, short-range communication system 712 in some examples. In addition, mobile computing device 730 may be used in conjunction with the vehicle control computers 717 for purposes of autonomous driving. Moreover, the processing components of the mobile computing device 730 may be used to identify vehicle drivers and passengers, analyze vehicle driving data, analyze driving trips, and perform other related functions. Therefore, in certain embodiments, mobile computing device 730 may be used in conjunction with, or in place of, the insurance system server 750.

[0116] Vehicle 710 may include driving analysis computer 714, which may be separate computing devices or may be integrated into one or more other components within the vehicle 710, such as the telematics device 713, autonomous driving systems, or the internal computing systems of vehicle 710. As discussed above, driving analysis computers 714 also may be implemented by computing devices independent from the vehicle 710, such as mobile computing device 730 of the drivers or passengers, or one or more separate computer systems (e.g., a user's home or office computer). In any of these examples, the driving analysis computer 714 may contain some or all of the hardware/software components as the computing device 1301 depicted in FIG. 13. Further, in certain implementations, the functionality of the driving analysis computers, such as storing and analyzing driver data, vehicle data, driving data and driving behaviors, and determining, presenting, and implementing aspects of road segment safety rating, may be performed in a central insurance system server 750 rather than by the individual vehicle 710 or personal mobile device 730. In such implementations, the vehicle 710 and and/or mobile device 730, might only collect and transmit driver data, vehicle data, driving data, and the like to an insurance server 750, and thus the vehicle-based driving analysis computer 714 may be optional.

[0117] The system 700 also may include one or more insurance system servers 750, containing some or all of the hardware/software components as the computing device 1301 depicted in FIG. 13. The insurance system server 750 may include hardware, software, and network components to receive driver data, vehicle data, and vehicle operational data/driving data from one or more vehicles 710, mobile devices 730, and other data sources. The insurance system server 750 may include an insurance database 752 and road segment safety rating system 751 to respectively store and analyze driver data, vehicle data, and driving data, etc., received from vehicle 710, mobile device 730, and other data sources. In some examples, the road segment safety rating system 751 may include many or all of the components of road segment safety rating system 600 described with respect to FIG. 6.

[0118] The insurance system server 750 may initiate communication with and/or retrieve driver data, vehicle data, and driving data from vehicle 710 wirelessly via telematics device 713, mobile device 730, or by way of separate computing systems over one or more computer networks (e.g., the Internet). Additionally, the insurance system server 750 may receive additional data from other third-party data sources, such as external traffic databases containing traffic data (e.g., amounts of traffic, average driving speed, traffic speed distribution, and numbers and types of accidents, etc.) at various times and locations, external weather databases containing weather data (e.g., rain, snow, sleet, and hail amounts, temperatures, wind, road conditions, visibility, etc.) at various times and locations, and other external data sources containing driving hazard data (e.g., road hazards, traffic accidents, downed trees, power outages, road construction zones, school zones, and natural disasters, etc.), route and navigation information, and insurance company databases containing insurance data (e.g., driver score, coverage amount, deductible amount, premium amount, insured status) for the vehicle, driver, and/or other nearby vehicles and drivers.

[0119] Data stored in the insurance database 752 may be organized in any of several different manners. For example, a driver table in database 752 may contain all of the driver data for drivers associated with the insurance provider (e.g., driver personal information, insurance account information, demographic information, accident histories, risk factors, driving scores and driving logs, etc.), a vehicle table may contain all of the vehicle data for vehicles associated with the insurance provider (e.g., vehicle identifiers, makes, models, years, accident histories, maintenance histories, travel logs, estimated repair costs and overall values, etc.), and a driving trip table may store all of the driving trip data for drivers and vehicles associated with the insurance provider (e.g., road segment identification, road segment safety rating, driving trip driver, vehicle driven, trip time, starting and ending points, route driven, etc.). Other tables in the database 752 may store additional data, including data types discussed above (e.g. traffic information, road-type and road condition information, weather data, insurance policy data, etc.). Additionally, one or more other databases of other insurance providers containing additional driver data and vehicle data may be accessed to retrieve such additional data.

[0120] The road segment safety rating system 751 within the insurance system server 750 may be configured to retrieve data from the database 752, or may receive driver data, vehicle data, and driving trip directly from vehicle 710, mobile device 730, or other data sources, and may perform driving data analyses, determine or generate road segment safety ratings, and other related functions. The functions performed by the road segment safety rating system 751 may be performed by specialized hardware and/or software separate from the additional functionality of the insurance system server 750. Such functions may be similar to those of driving analysis module 714 of vehicle 710, and the driving analysis and road segment safety rating applications 734 and 735 of mobile device 730, and further descriptions and examples of the algorithms, functions, and analyses that may be executed by the road segment safety rating system 751 are described below, including in reference to FIGS. 8-12B.

[0121] In various examples, the driving data and driving trip analyses and/or road segment safety determinations may be performed entirely in the insurance system server 750, may be performed entirely in the vehicle-based driving analysis computing module 714, or may be performed entirely in the driving analysis and road segment safety rating applications 734 and 735 of mobile device 730. In other examples, certain analyses of driver data, vehicle data, and driving trip data, and certain road segment safety rating determinations may be performed by vehicle-based devices (e.g., within driving analysis module 714) or mobile device 730 (e.g., within applications 734 and 735), while other data analyses and road segment safety rating determinations are performed by the road segment safety rating system 751 at the insurance system server 750. For example, a vehicle-based driving analysis computer 714, or the hardware and software components of mobile device 730 may continuously receive and analyze driver data, vehicle data, driving trip data, and the like to determine certain events and characteristics (e.g., commencement of a driving trip, identification of a driver, determination of a driving route, road segment, or intended destination, driving data and behaviors during driving trips, etc.), so that large amounts of data need not be transmitted to the insurance system server 750. However, for example, after driver, vehicle, and/or driving trip is determined by a vehicle-based device and/or mobile device, corresponding information may be transmitted to the insurance server 750 to perform alternate road segment recommendation determinations, insurance offer and cost determinations, etc. which may be transmitted back to the vehicle-based device and/or personal mobile devices.

[0122] FIG. 8 is a flow chart illustrating one example method of determining a road segment safety rating, according to one or more aspects described herein. In step 800, historical data is received by the system. As discussed above, the historical data may include data from multiple sources that are either (or both) internal to and external to the entity implanting the system. The historical data may include traffic volume data, accident data, severity of accidents, type of road on which accidents occurred, road type, and the like. The historical data may further include information associated with various road conditions, features, etc. For example, historical data may include information such as bends in a road or road segment, lane mergers or changes in a road or road segment, cloverleaf interchanges, speed limit of the road or road segment, average speed in relation to speed limit, angle of the sun, time of day, condition of road (e.g., potholes, etc.), curvature of the road, degree of bank on the road, whether pedestrians may be present on or near the road, neighborhood crime statistics, whether the road or road segment is in a residential or commercial area, the season of the year, whether one or more congestion causing events may occur, etc. This data may be received from a variety of sources providing information associated with a plurality of roads and road segments and may be used, as discussed herein, to determine road segment safety ratings for a plurality of road segments. Various other types of data (e.g., historical and real-time or near real-time may also be received and used herein without departing from the invention.

[0123] In step 802, location information for a vehicle may be received. In some examples, the location information may be received from a GPS device or system associated with the vehicle. Based on the received location information, a current road segment of the vehicle may be determined in step 804.

[0124] In step 806, a road segment safety rating of the road segment identified or determined in step 804 may be generated. As discussed above, the road segment safety rating may be based on the data received (e.g., in step 802) and may be indicative of a safety level of the road segment, as determined from historical driving data associated with that road segment. In step 808, the determined road segment safety rating may be transmitted to the user, e.g., via one or more computing device. For instance, the road segment safety rating may be transmitted to the user via a mobile device of the user and/or an on-board vehicle computing device.

[0125] FIG. 9 illustrates another example method of determining a road segment safety rating according to one or more aspects described herein. In step 900, historical information may be received. Similar to step 800, the historical information may be received from one or more sources and may include various types of information associated with one or more roads or road segments, traffic, and the like. In step 902, location information may be received from a vehicle. Similar to step 802, the location information may be received from a GPS system associated with the vehicle.

[0126] In step 904, a road segment on which the vehicle is travelling may be identified based on the received location information. In step 906, driver-specific information may be received. As discussed above, the driver-specific information may include driver behaviors determined from data collected from one or more sensors associated with a vehicle. The driving behaviors may be determined over a period of time (e.g., one month, one year, multiple years, etc.). In some examples, the driver-specific information received may be raw sensor data received from one or more sensors associated with the vehicle. For instance, the data may be real-time or near real-time driving data indicative of weather conditions, road conditions, or the like.

[0127] In step 908, a safety rating for the identified road segment may be determined based on the received historical information and the received driver-specific information. Accordingly, in such examples, the safety rating determined in step 908 may be particular or unique to the driver, because it relies on driving behaviors of the driver to determine the rating. Thus, any given road segment may have a different safety rating for various different drivers based on the driving behavior information used to determine the road segment safety rating.

[0128] In step 910, a determination may be made as to whether the determined road segment safety rating is at or above a predetermined threshold. If so, a notification may be transmitted to the user or driver in step 912 indicating the road segment safety rating. As discussed above, the notification may be transmitted to one or more computing devices of the user, such as a mobile device of the user, on-board vehicle computing device, or the like.

[0129] If, in step 910, it is determined that the road segment safety rating is below the predetermined threshold, one or more recommendations for alternate road segments may be generated in step 914. As discussed above, the recommendations may be generated based on a comparison between the road segment and other road segments in a similar geographic location. In some examples, for instance when a user has indicated a destination of the trip, the system may generate an alternate route to the destination that includes road segments having safer ratings than the current road segment or current route. These determinations may be performed by one or more computing devices within the system and may process vast amounts of data associated with road segments, potential routes, road segment safety ratings, and the like, that would be difficult or impossible to be determined by a person without the aid of a computing device.

[0130] In some examples, the recommendations generated may be based, at least in part, on driving behaviors of the user. For instance, behaviors such as speed relative to the speed limit, speed relative to other drivers, braking distance, following distance, and the like, that have been determined, such as by a driving behaviors module based on received sensor data, may be used to identify road segments that would be suited to the driving behaviors of the user and may have a safer rating.

[0131] In step 916, the one or more recommendations may be transmitted to the user. Similar to the transmission of the road segment safety rating in step 912, the recommendations may be transmitted to a computing device of the user, such as a mobile device or on-board vehicle computing device of the user's vehicle.

[0132] FIGS. 10A and 10B are example user interfaces illustrating notifications that may be transmitted to the user based on the determined road segment safety rating. FIG. 10A includes user interface 1000 that may be presented to a user upon determining that the road segment safety rating is at or above the predetermined threshold. The interface 1000 may be provided to the user via a computing device, such as a mobile device of the user and/or a display of an on-board vehicle computing device. The interface includes region 1002 in which the road segment safety rating is provided to the user. The interface 1000 includes “OK” option 1004. Selection of option 1004 may cause the display to return to a previous screen (e.g., a navigation screen, an audio selection screen, etc.). Additionally or alternatively, the interface 600 may be displayed for a predetermined time period and then the display may automatically revert back to the previous screen. For instance, the road segment safety rating may be displayed for, for example, 10 seconds, 15 seconds, or the like, and then the display may automatically revert back to the screen displayed prior to displaying the road segment safety rating. In some examples, an audible warning may also be provided to the user. For instance, a spoken alert or other audible warning may be provided either in addition to or in lieu of the displayed warning.

[0133] FIG. 10B illustrates example user interface 1050. Interface 1050 may be displayed upon determining that the road segment safety rating for the current road segment is below the predetermined threshold. Interface 1050 includes region 1052 in which the current road segment safety rating is provided to the user. In addition, interface 1050 further includes region 1054 in which one or more alternate routes or roads are provided to the user. The user may select one of the options provided and the system may automatically generate navigation directions (or turn-by-turn directions) to transition to the selected route.

[0134] The interfaces shown in FIGS. 10A and 10B are merely some example interfaces that may be used to provide road segment safety rating information to a user. Various other interfaces, interface arrangements, and information may be provided to the user without departing from the invention.

[0135] FIG. 11 is one example method of identifying insurance premiums or incentives based on the determined road segment safety ratings, according to one or more aspects described herein. In step 1100, a road segment safety rating may be determined. The road segment safety rating may be determined using one or more of the processes described herein and, in particular, in connection with FIGS. 8 and 9.

[0136] In step 1102, the road segment safety rating may be analyzed along with one or more insurance policy parameters of an auto insurance policy of the user or vehicle. For instance, a history of high safety road segments traveled by the user or vehicle may result in an option for a reduction in insurance premium, offer of a discount on a premium, or the like. In another example, if the insurance policy is a pay as you drive type of policy, the road segment safety rating may be used to determine a rate at which the credits within the insurance policy are reduced. For instance, as the vehicle travels a route, the safety rating of the road segments traveled may be determined, as discussed herein. Accordingly, the system may determine a rate at which to reduce the insurance credits associated with this trip based at least in part on the road segment safety ratings of one or more road segments traveled. That is, travelling along road segments having a safer rating may result in a lower consumption rate of insurance credits (e.g., credits will last longer, thereby saving the user money associated with purchase of the policy, credits, etc.) than travelling along road segments having a less safe rating, as determined by the system. This may provide the user with an incentive to travel on roads or road segments having safer ratings.

[0137] In step 1104, one or more insurance incentives to offer to the user may be generated. Insurance incentives may include a lower premium, a discount on a premium, an amount of cash reward, or the like. In step 1106, the insurance incentive may be transmitted to the user. For instance, the generated one or more incentives may be transmitted to a computing device of a user and displayed therein.

[0138] FIGS. 12A and 12B illustrate example user interfaces that may be provided to a user to identify one or more insurance incentives according to one or more aspects described herein. FIG. 12A includes interface 1200a in which the user is notified that his or her safe driving (e.g., selection of road segments having a good safety rating) has earned him or her an insurance discount. Similar to various other notifications described herein, the notification may be transmitted to a computing device of the user, such as a mobile device, on-board vehicle computing device display, or the like. The notification may also be in audible notification projected from the computing device. Upon receiving the notification, the user may elect to move forward with processing the insurance incentive by selecting “OK” option, or may request that the system send a reminder notification at a later time. In some examples, upon selection of “Remind me later” option, the system may automatically transmit a reminder notification at preset times or intervals (e.g., 1 hour later, 24 hours later, 3 days later, etc.).

[0139] Selection of “OK” option from interface 1200a may prompt interface 1200b, or similar, as shown in FIG. 12B. Interface 1200b identifies the insurance incentive being offered to the user (e.g., a 10% discount in this example). Various other incentives or types of incentives may be provided to the user without departing from the invention. For instance, discounts may be offered to avoid driving on particular road segments (e.g., road segments having a less safe rating).

[0140] If the user wishes to accept the offered incentive, he or she may select “ACCEPT” option. Alternatively, if the user does not wish to accept the offered incentive, he or she may select “NO, THANKS” option. Selection of “NO, THANKS” option may cause the incentive to be stored in the system for a pre-determined period of time (e.g., one week, one month, etc.) so that the user may return to the system and accept the incentive. However, in some arrangements, selection of “NO, THANKS” option may indicate that the user is not interested and, thus, no reminder notifications will be sent.

[0141] The systems, methods, and the like, described herein provide arrangements for determine a safety rating of a road segment that may be used to improve safe driving of a user, provide insurance incentives to the user, and the like. The use of road segments, rather than a “road” in general, may provide for additional granularity in the analysis. For instance, use of road segments may allow for the system to account for changes in the number of lanes, particular sections of a road that are in disrepair, sections of a road having more curves than other portions, changes in the municipality overseeing the road, and the like. Accordingly, a more accurate safety rating for road segments, roads, and entire routes may be provided to the user.

[0142] Further, the road segment safety rating system may be used to provide coaching aspects to one or more drivers. For instance, by making recommendations of safer road segments or routes, the system may aid drivers in identifying safe routes, etc. This aspect may be useful for various drivers and, for example, new drivers (e.g., teenagers).

[0143] Further, determination of suggested routes based on road segment safety ratings may be useful to non-insurance entities (in addition to insurance entities, such as entities that provide applications directed to navigation, identifying desirable neighborhoods, identifying roads in need of construction, designing new roadways, etc.

[0144] The arrangements described herein may also have commercial applicability in that trucks or vehicles of a certain size or weight may be prevented from travelling on certain road segments or routes. Accordingly, shipping costs may be varied based on the safety rating of one or more road segments traveled by the vehicle.

[0145] As discussed herein, the systems, arrangements, processed, etc. discussed herein may be used in various computing environments and/or with various computing devices. FIG. 13 illustrates a block diagram of a computing device (or system) 1301 in a computer system 1300 that may be used according to one or more illustrative embodiments of the disclosure. The device 1301 may have a processor 1303 for controlling overall operation of the device 1301 and its associated components, including RAM 1305, ROM 1307, input/output module 1309, and memory 1315. The computing device 1301, along with one or more additional devices (e.g., terminals 1341, 1351, and 1361, security and integration hardware 1360) may correspond to any of multiple systems or devices described herein, such as personal mobile devices, vehicle-based computing devices, insurance systems servers, external data sources and other various devices in a risk unit based insurance system. These various computing systems may be configured individually or in combination, as described herein, for determining and/or providing road segment safety ratings (e.g., based on historical accident and/or traffic information, driver specific behavior data, etc.), determining insurance rates associated with a particular road segment, generating recommendations for road segments with safer ratings, and the like, using the devices of the road segment safety rating systems described herein. In addition to the features described above, the techniques described herein also may be used for generating and presenting insurance recommendations to customers, insurance underwriting, and other insurance-related tasks.

[0146] Input/Output (I/O) 1309 may include a microphone, keypad, touch screen, and/or stylus through which a user of the computing device 1301 may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output. Software may be stored within memory 1315 and/or storage to provide instructions to processor 1303 for enabling device 1301 to perform various actions. For example, memory 1315 may store software used by the device 1301, such as an operating system 1317, application programs 1319, and an associated internal database 1321. The various hardware memory units in memory 1315 may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Certain devices and systems within the road segment safety rating systems may have minimum hardware requirements in order to support sufficient storage capacity, processing capacity, analysis capacity, network communication, etc. For instance, in some embodiments, one or more nonvolatile hardware memory units having a minimum size (e.g., at least 1 gigabyte (GB), 2 GB, 5 GB, etc.), and/or one or more volatile hardware memory units having a minimum size (e.g., 256 megabytes (MB), 512 MB, 1 GB, etc.) may be used in a device 1301 (e.g., a personal mobile device 1301, vehicle-based device 1301, insurance system server 1301, etc.), in order to collect and analyze driver data, vehicle data, traffic data, and/or accident data, determine a safety rating for a road segment, determine an insurance rate or cost associated with the road segment, etc., using the various devices of the road segment safety rating systems. Memory 1315 also may include one or more physical persistent memory devices and/or one or more non-persistent memory devices. Memory 1315 may include, but is not limited to, random access memory (RAM) 1305, read only memory (ROM) 1307, electronically erasable programmable read only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by processor 1303.

[0147] Processor 1303 may include a single central processing unit (CPU), which may be a single-core or multi-core processor (e.g., dual-core, quad-core, etc.), or may include multiple CPUs. Processor(s) 1303 may have various bit sizes (e.g., 16-bit, 32-bit, 64-bit, 96-bit, 128-bit, etc.) and various processor speeds (ranging from 100 MHz to 5 Ghz or faster). Processor(s) 1303 and its associated components may allow the system 1301 to execute a series of computer-readable instructions, for example, to receive and analyze driver data, vehicle data, traffic data and/or accident data, determine a safety rating for a road segment, generate recommendations for alternate road segments having a safer rating, and the like.

[0148] The computing device (e.g., a personal mobile device, vehicle-based system, insurance system server, etc.) may operate in a networked environment 1300 supporting connections to one or more remote computers, such as terminals 1341, 1351, and 1361. Such terminals may be personal computers or servers 1341 (e.g., home computers, laptops, web servers, database servers), mobile communication devices 1351 (e.g., mobile phones, tablet computers, etc.), vehicle-based computing systems 1361 (e.g., on-board vehicle systems, telematics devices, mobile phones or other personal mobile devices within vehicles), and the like, each of which may include some or all of the elements described above with respect to the computing device 1301. The network connections depicted in FIG. 13 include a local area network (LAN) 1325 and a wide area network (WAN) 1329, and a wireless telecommunications network 1333, but may also include other networks. When used in a LAN networking environment, the computing device 1301 may be connected to the LAN 1325 through a network interface or adapter 1323. When used in a WAN networking environment, the device 1301 may include a modem 1327 or other means for establishing communications over the WAN 1329, such as network 1331 (e.g., the Internet). When used in a wireless telecommunications network 1333, the device 1301 may include one or more transceivers, digital signal processors, and additional circuitry and software for communicating with wireless computing devices 1351 and 1361 (e.g., mobile phones, portable customer computing devices, vehicle-based computing devices and systems, etc.) via one or more network devices 1335 (e.g., base transceiver stations) in the wireless network 1333.

[0149] Also illustrated in FIG. 13 is a security and integration layer 1360, through which communications are sent and managed between the device 1301 (e.g., a personal mobile device, a vehicle-based computing device, an insurance server, an intermediary server and/or external data source servers, etc.) and the remote devices (1341, 1351, and 1361) and remote networks (1325, 1329, and 1333). The security and integration layer 1360 may comprise one or more separate computing devices, such as web servers, authentication servers, and/or various networking components (e.g., firewalls, routers, gateways, load balancers, etc.), having some or all of the elements described above with respect to the computing device 1301. As an example, a security and integration layer 1360 of a server 1301 may comprise a set of web application servers configured to use secure protocols and to insulate the device 1301 from external devices 1341, 1351, and 1361. In some cases, the security and integration layer 1360 may correspond to a set of dedicated hardware and/or software operating at the same physical location and under the control of same entities as device 1301. For example, layer 1360 may correspond to one or more dedicated web servers and network hardware in a vehicle and driver information datacenter or in a cloud infrastructure supporting a cloud-based vehicle identification and vehicle and driver data retrieval and analysis. In other examples, the security and integration layer 1360 may correspond to separate hardware and software components which may be operated at a separate physical location and/or by a separate entity.

[0150] As discussed herein, the data transferred to and from various devices in a road segment safety rating system 1300 may include secure and sensitive data, such as confidential vehicle operation data, insurance policy data, and confidential user data from drivers and passengers in vehicles. Therefore, it may be desirable to protect transmissions of such data by using secure network protocols and encryption, and also to protect the integrity of the data when stored on the various devices within a road segment safety rating system, such as personal mobile devices, vehicle-based devices, insurance servers, external data source servers, or other computing devices in the system 1300, by using the security and integration layer 1360 to authenticate users and restrict access to unknown or unauthorized users. In various implementations, security and integration layer 1360 may provide, for example, a file-based integration scheme or a service-based integration scheme for transmitting data between the various devices in an electronic display system 1300. Data may be transmitted through the security and integration layer 1360, using various network communication protocols. Secure data transmission protocols and/or encryption may be used in file transfers to protect the integrity of the data, for example, File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), and/or Pretty Good Privacy (PGP) encryption. In other examples, one or more web services may be implemented within the various devices 1301 in the system 1300 and/or the security and integration layer 1360. The web services may be accessed by authorized external devices and users to support input, extraction, and manipulation of the data (e.g., vehicle data, driver data, driving trip data, etc.) between the various devices 1301 in the system 1300. Web services built to support a personalized display system may be cross-domain and/or cross-platform, and may be built for enterprise use. Such web services may be developed in accordance with various web service standards, such as the Web Service Interoperability (WS-I) guidelines. In some examples, a driver data, vehicle data, traffic data, and/or accident data analysis web service, road segment safety analysis web service, insurance rate analysis web service, etc. may be implemented in the security and integration layer 1360 using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to provide secure connections between servers 101 and various clients 1341, 1351, and 1361. SSL or TLS may use HTTP or HTTPS to provide authentication and confidentiality. In other examples, such web services may be implemented using the WS-Security standard, which provides for secure SOAP messages using XML encryption. In still other examples, the security and integration layer 1360 may include specialized hardware for providing secure web services. For example, secure network appliances in the security and integration layer 1360 may include built-in features such as hardware-accelerated SSL and HTTPS, WS-Security, and firewalls. Such specialized hardware may be installed and configured in the security and integration layer 1360 in front of the web servers, so that any external devices may communicate directly with the specialized hardware.

[0151] Although not shown in FIG. 13, various elements within memory 1315 or other components in system 1300, may include one or more caches, for example, CPU caches used by the processing unit 1303, page caches used by the operating system 1317, disk caches of a hard drive, and/or database caches used to cache content from database 1321. For embodiments including a CPU cache, the CPU cache may be used by one or more processors in the processing unit 1303 to reduce memory latency and access time. In such examples, a processor 1303 may retrieve data from or write data to the CPU cache rather than reading/writing to memory 1315, which may improve the speed of these operations. In some examples, a database cache may be created in which certain data from a database 1321 (e.g., a database of driver data, driving behaviors or characteristics, passenger-related data, vehicle data, traffic data, accident data, etc.) is cached in a separate smaller database on an application server separate from the database server (e.g., at a personal mobile device, vehicle-based data, or intermediary network device or cache device, etc.). For instance, in a multi-tiered application, a database cache on an application server can reduce data retrieval and data manipulation time by not needing to communicate over a network with a back-end database server. These types of caches and others may be included in various embodiments, and may provide potential advantages in certain implementations of risk unit based insurance systems, such as faster response times and less dependence on network conditions when transmitting and receiving driver information, vehicle information, traffic information, accident information, road segment safety rating information, and the like.

[0152] It will be appreciated that the network connections shown are illustrative and other means of establishing a communications link between the computers may be used. The existence of any of various network protocols such as TCP/IP, Ethernet, FTP, HTTP and the like, and of various wireless communication technologies such as GSM, CDMA, WiFi, and WiMAX, is presumed, and the various computing devices in risk unit based insurance system components described herein may be configured to communicate using any of these network protocols or technologies.

[0153] Additionally, one or more application programs 1319 may be used by the various computing devices 1301 within a road segment safety rating system 1300 (e.g., vehicle data, driver data, traffic data, and/or accident data, analysis software applications, location determining software applications, etc.), including computer executable instructions for receiving and analyzing various driver data, vehicle data, traffic data and/or accident data, determining location of a vehicle, determine a safety rating for a road segment, and/or generating recommendations for alternate road segments having higher safety ratings using the devices of the road segment safety rating systems.

[0154] As discussed herein, determined road segment safety ratings may be determined and stored (e.g., in an on-board vehicle system, in a remote system, etc.). In some examples, at the completion of each trip, a determined road segment safety rating may be transmitted to an insurance provider and may be stored at an insurance provider system.

[0155] Further, although various examples discussed herein are directed to determining a road segment safety rating based on environmental or external factors, driver behavior, and the like, the data collected may further be used to identify hazards or risks along a route or projected route of a user. For instance, data associated with an accident that has recently occurred may be coupled with the driver's characteristic driving data to provide a warning to the user of the upcoming accident. That is, if the driver has a history of driving faster than the speed limit, or data indicated the driver is currently driving faster than the speed limit, and the accident identified is a short distance ahead, a warning or alert (e.g., displayed or audible) may be provided to the user indicating that an accident is ahead and the user should reduce speed. Various other arrangements in which external data is combined with driving behaviors to identify risk and alert drivers may be used without departing from the invention.

[0156] Although various implementations of the systems, methods, etc. described herein are provided above, below is one example of how the road segment safety rating system may be used. The example below is not intended to limit the arrangements discussed herein to only this implementation. Rather, the arrangements described herein may be implemented in various other ways without departing from the invention.

[0157] In one example, a driver may be provided with a plurality of routes to a particular destination upon identifying a destination (either by driver input or as predicted by the system). The plurality of routes provided may each have a different overall road safety rating (e.g., based on safety ratings of road segments comprising each route). The driver may then proceed to the identified destination via one of the plurality of routes, a combination of the identified routes, or via another route. Upon completion of the trip, an overall road segment safety rating for the route taken may be determined. This safety rating may then be transmitted to an insurance provider system for storage and use (as discussed herein).

[0158] In some examples, the overall safety rating of trips taken in a predetermined period of time (e.g., one month, three months, six months, etc.) may be evaluated (by the insurance provider system) and a discount or other incentive to provide to the driver may be generated based on this evaluation. The discount or incentive may then be applied to a next policy period.

[0159] While the aspects described herein have been discussed with respect to specific examples including various modes of carrying out aspects of the disclosure, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques that fall within the spirit and scope of the invention.